Re: r26700 - docs/Perl6/Spec
Moritz Lenz wrote: Jon Lang wrote: @@ -1836,6 +1836,12 @@ prototype objects, in which case stringification is not likely to produce something of interest to non-gurus.) +The C<.^parents> method by default returns a flattened list of all +parents sorted in MRO (dispatch) order. Other options are: + +:local just returns the immediate parents +:hierarchical the inheritance heirarchy as nested arrays Bad Huffman coding, IMHO. Could we s/hierarchical/tree/? Huffman coding? How often do you you call meta object methods? Anyway, I agree that :tree would be nicer (notice that "hierarchical" is sufficiently hard to type so it's typed wrongly in 50% of the occurrences ;-)) I've found 2 different ways to misspell hierarcha^Whierachi^W*sigh* already while stubbing that flag into Rakudo yesterday. So I'd happily see it become tree. If there's no objections soonish, let's change it to that. Jonathan
Re: r26700 - docs/Perl6/Spec
Jon Lang wrote: >> @@ -1836,6 +1836,12 @@ >> prototype objects, in which case stringification is not likely to >> produce something of interest to non-gurus.) >> >> +The C<.^parents> method by default returns a flattened list of all >> +parents sorted in MRO (dispatch) order. Other options are: >> + >> +:local just returns the immediate parents >> +:hierarchical the inheritance heirarchy as nested arrays > > Bad Huffman coding, IMHO. Could we s/hierarchical/tree/? Huffman coding? How often do you you call meta object methods? Anyway, I agree that :tree would be nicer (notice that "hierarchical" is sufficiently hard to type so it's typed wrongly in 50% of the occurrences ;-)) Moritz
Re: r26700 - docs/Perl6/Spec
> @@ -1836,6 +1836,12 @@ > prototype objects, in which case stringification is not likely to > produce something of interest to non-gurus.) > > +The C<.^parents> method by default returns a flattened list of all > +parents sorted in MRO (dispatch) order. Other options are: > + > + :local just returns the immediate parents > + :hierarchical the inheritance heirarchy as nested arrays Bad Huffman coding, IMHO. Could we s/hierarchical/tree/? -- Jonathan "Dataweaver" Lang
r26700 - docs/Perl6/Spec
Author: jnthn Date: 2009-05-06 15:36:27 +0200 (Wed, 06 May 2009) New Revision: 26700 Modified: docs/Perl6/Spec/S12-objects.pod Log: [spec] Rename ^isa() to get list of parents to ^parents so there's no confusion with .^isa(Foo) and consistency with .^does(Foo) and .^roles(). Also fill out the introspection specification a little more. Modified: docs/Perl6/Spec/S12-objects.pod === --- docs/Perl6/Spec/S12-objects.pod 2009-05-06 12:14:10 UTC (rev 26699) +++ docs/Perl6/Spec/S12-objects.pod 2009-05-06 13:36:27 UTC (rev 26700) @@ -1821,7 +1821,7 @@ subject optics, boxes language ja_JP licensed Artistic|GPL -isa list of parent classes +parents list of parent classes roles list of roles disambig how to deal with ambiguous method names from roles layoutP6opaque, P6hash, P5hash, P5array, PyDict, Cstruct, etc. @@ -1836,6 +1836,12 @@ prototype objects, in which case stringification is not likely to produce something of interest to non-gurus.) +The C<.^parents> method by default returns a flattened list of all +parents sorted in MRO (dispatch) order. Other options are: + +:local just returns the immediate parents +:hierarchical the inheritance heirarchy as nested arrays + The C<.^methods> method returns method-descriptors containing: namethe name of the method @@ -1848,6 +1854,10 @@ specify whether you want to see a flattened or hierarchical view, whether you're interested in private methods, and so forth. +:local only methods defined in the current class +:hierarchical methods by class structure (inheritance hierarchy) +:privateinclude private methods + The C<.^attributes> method returns a list of attribute descriptors that have traits like these: @@ -1860,6 +1870,11 @@ build readonly +It also takes the parameters: + +:local only methods defined in the current class +:hierarchical attributes by class structure (inheritance hierarchy) + Strictly speaking, metamethods like C<.isa()>, C<.does()>, and C<.can()> should be called through the meta object:
