On 2/8/06, Stephen Gilson <[EMAIL PROTECTED]> wrote: > The idea of a single table that shows all the class elements, both > defined in the class and inherited, is a bit daunting. For example, the > table for the DataGrid would contain over 200 rows, probably closer to > 250 rows.
I appreciate that some classes will have that many methods and properties (we are talking public ones?), and that a single table showing all elements is daunting. However, even more daunting is trying to get a birds eye view of a class, when you're an inch off the ground! That's certainly how I feel, when I look at the class summary of a class like the DataGrid. I just thought of an issue (and this may be off topic) with highly specialised classes. When a class has large family tree, the names/meanings of methods/properties of ancestor classes tend be very generic and many not make sense in the specialised decedent class. What mechanisms are in place to rename ancestor methods/properties so they make sense in the context of the decedent class. This issue is important when learning a new class that has a large family tree, because you are trying to understand what this class can do for you and generic names can slow you down. Chris -- Chris Velevitch Manager - Sydney Flash Platform Developers Group www.flashdev.org.au -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
