On Wed, Sep 07, 2005 at 12:27:20PM -0400, Stevan Little wrote:
: How do I differentiate a method from a sub? Wouldn't they both have the
: & sigil?
Yes, as it currently stands, you can only tell that by introspection.
: >: class Foo;
: >: has $.baz;
: >: method bar { ... }
: >:
: >: Can I get to $.baz? If I can, what will I get?
: >
: >All sigils and twigils are part of the key to the symbol table, so it's
: >now just
: >
: > Foo<$.baz>
:
: What would Foo<$.baz> return though (assuming Foo is a class)? It
: cannot return a value since it is an instance specific value.
Foo<@baz> is not a value either, but a container. I would say that
Foo<$.baz> returns a generic container that happens not to work
without an extra instance argument to say which chunk of data to map
the container metainfo onto.
: Should it return some kind of meta-object?
Yes.
:Or possibly the default value specified (if one is specified)?
No, symbol tables don't hold values. (We once thought about making
the attribute return the default value within class methods (in fact
the Apocalypse espouses that, if I recall) but we eventually decided
that it was a confusing idea.)
: Can this value be written too?
Only via introspection.
: If so, how does that affect things?
Doesn't, since you can't.
: Also would/should this work:
:
: $iFoo<$.baz>
Yes, but...
: As a means of breaking the opaque instance data structure. (I for one,
: vote no on that).
It would still get you the metacontainer, which these days still
represents an virtual call and thus doesn't break encapsulation.
The name of the non-virtual storage for $.baz is currently $._baz
(with a private ._baz() accessor akin to the old .:baz() accessor),
and we presumably take steps to prevent people from breaking any "_"
encapsulation trivially. (The debugger needs to get at the info,
of course, which basically means anyone can if they pretend to be
the debugger, but we don't have to make it easy...)
Larry
