Many thanks.
Larry Wall larry-at-wall.org |Perl 6| wrote:
self!BaseName::attr should work, assuming BaseName trusts us.
Because it is an accessor function, not a syntax to reference a variable
in another scope. Got it.
But see my q's to Audrey. Why does it need the qualified name if the
same class as $obj's declared type, and just how is that being parsed
and/or implemented?
See S12:680 and following for how to pass protoobjects representing
partial construction without having to actually create intermediate
objects.
OK, I didn't understand what that was about when I read it. Now I see
it as analogous to the base/member syntax in C++.
I suppose any object would do, it doesn't have to be "but undefined", or
created using that Class{hash} syntax?
Every class maintains its own concrete, which is of no business to
anyone else, including derived classes. There is nothing like
protected in Perl 6. The closest you can get to it is "trusts",
and that's independent of class hierarchy.
It is my understanding that even Bjarne thinks "protected" is a bad idea
these days...
OK, so what is the more general mechanism of providing different
interfaces to different sets of trusted consumers? There is the
"protected interface" that I document to explain how a derived class is
to extend the functionality, and it has access to things the caller
doesn't, besides just being able to override functions. If there is no
special mechanism just for derived classes, I suppose you must have
something better in mind.
For example, sometimes a particular module (namespace, whatever) might
need a special insider interface, because they work together. But not
total trust like its own implementation! Another contract, distinct
from the public interface contract. That's a good name for it: multiple
contracts. "trusted" hands out access to all private instance data,
which is a special case.
Oh, and in C++, friendship can be granted to a function as well as to a
class. I suppose there is less need in Perl 6 since a global function
can be written as a method and exported. But consider a function that
operates on two different objects; it can only be the method of one. I
don't need to make the whole other class trusted, just this one function.
Also, since classes can be re-opened, anyone can grab trust from any
class anyway, just by declaring a new method inside that class.
--John
