On Thu, Jul 21, 2005 at 05:16:39PM +1200, Sam Vilain wrote:
: Making $.foo =:= $?SELF.foo, and getting to the "raw" attribute $.SUPER::foo
: seems like the better solution to me. But of course, it would, because
: that's
: how *I* program, and $?SELF != all(@coders).
:
: Then we could even sneak in making $.foo(bar) a not-so-offensive ./foo(bar),
: with ($.foo)(bar) meaning what $.foo(bar) currently means. But that really
: is a seperate issue, and speculation of it meaningless if we retain the
: current specified behaviour.
That's kind of the direction I've been thinking while I was driving,
but there are many ramifications. Of course, the nice thing about
ramifications is that it presents an opportunity to possibly clean
up some other infelicities, such as getting rid of the privacy colon,
which doesn't play well with the rest of the language, and which Damian
has been wanting to get rid of. It also lets us do some unification
of the private variables with the internal representation of public
variables, something Luke has been asking about for ages. It solves
the virtual redefinition problem posed by Sam, and it unifies the
concept of attribute and method "slots" under a single syntax. Oh,
it also is a solution to the self-call problem.
At the moment I'm thinking of something along these lines:
has $x; # private rw, no accessors, not virtual, name lexically scoped
has $_x; # private rw, rw _x accessor, not virtual, name class scoped
has $.x; # has read-only method
# $.x always virtual
# implies existence of "real" $_x internal variable
# $.x is itself read-only even in this class
# $_x may be set in methods or submethods
# both names are class scoped
has $.x is rw;
# has rw virtual method
# $.x is also always virtual
# implies existence of "real" $_x internal variable
# $.x is virtually rw in this class
# $_x is non-virtually rw in this class
# setting $_x limited to submethods
# warning if you set $_x in ordinary method
method x () {...}
# as before
method _x () {...}
# an explicitly private method
and possibly
has method x () {...}
# implicitly private method, not callable by trustees
# lexically scoped name like "has $x"
# could be "my method" instead
Other thinkings:
* Any self method can be called via $.x(@args) syntax, short for
$?SELF.x(@args).
* Any private method can be called via $_x(@args) syntax, short for
$?SELF._x(@args), assuming the private call is allowed at all.
* Trusted classes can use the $other._x(@args) syntax to call your private
accessors, but only on $_x attributes and _x methods, not on completely
private $x attributes.
* @.x(@args) is short for $?SELF.x(@args)[]
* %.x(@args) is short for $?SELF.x(@args){}
* &.x(@args) is short for $?SELF.x(@args).
* Extra parens are required when using this syntax to return a function
pointer that you then want to call, either $.x()() or ($.x)(). (Or
maybe we make &.x(@args) imply one set of parens.)
* All roles can write their shared attributes as $.x and not worry
about whether the class declares them or not.
* All roles can write completely private $x attributes that are not
visible outside their lexical scope but are nevertheless per-instance.
* All roles can write explicitly shared $_x attributes that are private
to the class but visible to other roles and trusted classes.
* You may not declare both $_x and $.x because a declaring of $.x is
actually declaring $_x underneath.
* You *may* declare both $x and $.x because they are invisible to each
other.
* "has $x" has no effect on method dispatch, either public or private.
* "has $_x" has no effect on public method dispatch.
* Don't need to topicalize self any more.
* .foo can (again) always be the topic without warnings.
Have at it...
Larry
