On Fri, Apr 04, 2008 at 09:41:26PM -0500, John M. Dlugosz wrote:
> But see my q's to Audrey. Why does it need the qualified name if the same
> class as $obj's declared type,
We could conceivably relax that if $obj has a declared type. But on
the other hand requiring the class name is pretty good documentation
for what could be viewed as a violation of propriety, even if the
other class has trusted us. It feels right to me from a huffman
coding point of view, anyway. I'm not opposed to making the user
jump through a few extra hoops for easily misunderstood constructs.
But maybe you can argue me out of it. :)
> and just how is that being parsed and/or implemented?
expect_term -> post -> dotty:<!> methodop -> name
So it would be implemented as a semantic constraint in any case, not
a syntactic one.
>> 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?
Possibly. Haven't really thought through the ramifications, and it
feels a bit like the problem of confusing clone with new. It would
be pretty easy for idioms to arise that create a lot of useless
temporary objects. You can only sweep so much under the carpet of
"the optimizer could fix it"...
In any case, the programmer really needs to keep straight when
an object is being used for its value vs when it's being used
for its type. Maybe that's not an issue here.
>> 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.
Feels like it wants some form of delegation to me. On the other
hand, contracts are generally expressed with roles in Perl 6, so
maybe there could be some way of limiting trust to the granularity
of a particular role's interface.
> 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.
We have another possible level of granularity there too, insofar as we
could trust a single multi or a proto that represents all multis in
its scope. Maybe a proto exported from within a class automatically
conveys trust to all normal multis (of the same name) declared the
import scope.
> Also, since classes can be re-opened, anyone can grab trust from any class
> anyway, just by declaring a new method inside that class.
Well, sure. But whenever the programmer does that, the Perl 6 compiler
will automatically send email to the programmer's supervisor. :)
Larry
