On Thu, Jul 21, 2005 at 10:17:13PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Larry Wall wrote:
: >    has $x;  # private rw, no accessors, not virtual, name lexically 
: >    scoped
: >
: >    has $_x; # private rw, rw _x accessor, not virtual, name class scoped
: Even if I come across as intellectually handicapped but could
: someone help me over this mental bridge: What is the difference
: between these two scopes?
: class Foo
: {
: #class scope starts here
:   has $x;  # where does this go if not Foo::x

The name goes into the lexical scope, but it generically represents
a slot in the instance.

:   has $_y; # this goes into Foo::_y
:   # both $x and $_y can be used in code from here on
:   # and refer to the same two things respectively, right?

$x is visible only in the rest of the lexical scope.  In contrast,
$_y would presumably still be visible if the class were reopened.

:   # or does class scope mean shared by all instances
:   # and lexically scopes per instance?

Class scope is basically package scope.  For instance attributes and
methods the package contains proxies representing the slots in the
actual instance.

: #class scope ends here
: }
: >Other thinkings:
: >
: >    * Any self method can be called via $.x(@args) syntax, short for
: >     $?SELF.x(@args).
: Isn't & the code sigil?

Sure, if you want to declare an attribute containing a code reference.
But & doesn't have much to do with the call syntax in any event,
whether you're calling subs or methods.  You can declare an attribute
as &.foo and call it as $.foo without a problem, since it's just
$?SELF.foo() either way, and the accessor methods are not associated
with sigils.  I think $.foo and &.foo are synonymous as attributes,
except insofar as we can probably deduce that &.foo is dealing with
a sub ref and not just any old scalar value.

: >    * All roles can write completely private $x attributes that are not
: >     visible outside their lexical scope but are nevertheless 
: >     per-instance.
: I understand that correctly, that $x in
:    role Foo { has $x = 7; method foo { $x++ } }
: denotes a reference to an Item from the data environment of the object
: that foo is invoked on.

I don't know what you mean by "data environment".  The second
occurrence of $x denotes the generic proxy declared by the "has"
that represents an eventual slot in the actual instance.  This slot
presumably has no other obvious name to any other role or to the
class that composes this role, though presumably there's an internal
way to get back from a particular slot to the slot's metadata, which
presumably knows which role supplied the definition.

: The type of the $?SELF that Foo is composed into
: obviously is a subtype of Foo. What happens with this hidden payload if
: the object changes its type such that it is no Foo anymore? E.g. by
: undefining the slot &.Foo::foo?

Um, people who undefine functions that are going to be called later get
what they deserve.  As for what happens to $x's slot in the absence
of the lexical reference from &Foo::foo, I expect the metadata would
still have pointers to it so it wouldn't necessarily be reclaimed
unless you told the object that is "undoes" Foo.  Or to look at it
another way, all the objects that "do" Foo have a closure over that
$x proxy, so it's not going to go away until everyone forgets about
the Foo role itself.


Reply via email to