On Fri, May 19, 2006 at 05:05:02PM -0700, Larry Wall wrote: > So what's in a name? One could say that .meta is functioning more like a > name sigil than like a method, and the Real Name of the metaobject is > Foo::<^Bar> or some such, if it needs a name.
Method, I like. Stealth sigil, I don't like. Generally, dependence on names for proper functioning of any programming construct -- variable, classe, whatever -- is in my experience almost invariably a design flaw, which ends up being rectified eventually (unless the enclosing system dies first), sometimes at significant cost to the thematic coherence of the system. For example, Perl 5 acquired references, and made anonymous subroutines, arrays, and hashes convenient. Where the language did not make something anonymous, modules came to the rescue (e.g. IO::Handle). I don't have to tell _you_ how much of Perl 4 became either vestigial or embarrasing in the transition, and how frustrating a _partial_ adaptation to anonymity became. Similarly, while it's taken decades, Unix variants are finally coming around to making most filesystem operations available on file descriptors rather than only on names. (fchown, fchmod, flink, etc.) So, if you want <arbitrary_expression>.meta to work, I think you should bite the bullet and admit that it actually *is* a method, or attribute, or anything else that's value-derived ... as long as it's not name-derived. You can't sigilize a name that isn't there. > Then maybe Foo::<Bar> is just a strange hash. Or maybe it has its own > sigil. But from the viewpoint of Dorothy the programmer, it's the package > that presents the public interface Oz::<Wizard>, and it's the metaobject > that's trying to hide behind the metacurtain. I think I don't understand you. However, if I do understand you, I disagree. Think through the use case of the entirely anonymous class -- the class which is not only nameless in the end, but which never had a name to begin with. (I'm not very familiar with prototype-based programming, but if I have the right inkling, anonymous prototype objects might even be the norm. But at this point I've begun speculating; so if that's wrong, ignore it.) Such an anonymous class, and objects of such a class, respond to named methods, to be sure; but the class *itself* has no name, and never did. Where do its methods live? Perhaps in a package, but of necessity that package has no name. (If the package name was merely obscure as opposed to nonexistent, it could not be garbage-collected when it was no longer in use, as its parent would continue to refer to it.) Furthermore, and perhaps most persuasively, I can easily imagine meta objects that have no use for a package at all, or that require several packages to respresent the partitioning of various subfunctions. Parrot's classes may be such metaobjects soon, as the HLL developers clamor to have the names introduced by the Parrot implementation completely segregated from their own work areas. Thus, choosing a _package_ as the owner of the primary entry point to a class's data structures -- that is, in the common case, it's name -- makes little sense to me. ------------------------------------------------- At the risk of plowing ground that has already been sold to developers: I would suggest that the type object in Perl 6 might well be the point of entry for the suite of (type,meta,package). The relationships would work like so: type object --> meta object {e.g. Class} --> package {optional} \-------> more packages? {possible} Note that the package(s) is (are) optional. Some metaobjects won't need them. For example, in Parrot, the metaobject for "namespace" doesn't point to a "namespace" object, for chicken-and-egg reasons. OTOH, it's possible for some metaobjects to need more than one. Getting back to the common case: the default behavior of Class creation will include creating names for the type object and the package object, and perhaps also for the metaobject, e.g.: Oz::<Wizard::> -------------------+ | Oz::<Wizard> | | | v v type object --> Class --> package ^ | Oz::<^Wizard>? -------+ Details of this second diagram are for illustration purposes only, to show that I'm not suggesting that everything be anonymous. My point is that the type system should (must!) still work even if no such names are ever assigned. I don't know the p6 lexical magic required to make it happen, but if the Wizard type object is anonymous, it should still be possible to say my <arbitrary_expression_returning_Wizard> $gandalf; and similarly it should be possible to use arbitrary expressions for all other type/meta operations including introspection, modification, subclassing, etc. -- Chip Salzenberg <[EMAIL PROTECTED]>