Many thanks.

Larry Wall |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

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.


Reply via email to