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]>
