Re: r30205 - docs/Perl6/Spec
A space between the colon and the opening brace ;-)
Leon
On Sat, Mar 27, 2010 at 2:01 AM, Geoffrey Broadwell wrote:
> On Fri, 2010-03-26 at 08:38 +0100, pugs-comm...@feather.perl6.nl wrote:
>> .doit: { $^a <=> $^b } # okay
>> .doit(): { $^a <=> $^b } # okay
>> .doit(1,2,3): { $^a <=> $^b } # okay
>> + .doit(1,2,3): { $^a <=> $^b } # okay
>
>> + .doit:{ $^a <=> $^b } # okay
>> + .doit():{ $^a <=> $^b } # okay
>> + .doit(1,2,3):{ $^a <=> $^b } # okay
>> + .doit(1,2,3):{ $^a <=> $^b } # okay
>
> My eyes must be playing tricks on me -- I can't see the difference
> between the last two lines in each of the above blocks. What am I
> missing?
>
>
> -'f
>
>
>
Re: You never have privacy from your children in Perl 6
On 03/26/2010 04:16 PM, Jason Switzer wrote: Also, this discussion of "trusts" piqued my interest; this sounds like a bad idea. Those of you who have worked extensively with C++ should bemoan "trusts" as much as friend classes. They break encapsulation for special cases, almost encouraging truly hideous object models that ultimately become purely public (painful on a large scale). I can't stress enough that if these are of similar nature, "trusts" should be removed. I'm all ears though if someone knows of a reason why they're more useful than onerous. -Jason "s1n" Switzer Here's the C++ FAQ Lite's answer to that: http://www.parashift.com/c++-faq-lite/friends.html#faq-14.2 I'm not necessarily sure that this applies to Perl 6 too much (I really haven't paid a ton of attention to access control), but I've always considered C++'s friends to be roughly equivalent to Java's package-private in terms of where they fit into one's notion of encapsulation - this is not to say that they are the same thing! Sean Hunt
Re: You never have privacy from your children in Perl 6
My own take on 'trusts' is that I consider its main purpose is to let programmers *avoid* contrivances when they want to define something that would otherwise be a single class but is split into multiple classes for better elegance. For example, say you want to define a graph of some kind, and for elegance you have a separate container and node and side classes, even though conceptually these are all integrated parts of a whole. Say in this case your container class has a list of all its child nodes and each node has a pointer to its container. Often you'd want to invoke a method which would then ensure that pointers in both classes are updated but you don't want it to be possible for users to just update one or the other but not both. Sounds like private, but 'trusts' makes it work well. Suffice it to say I consider 'trusts' to be very important but best used for limited cases like what I mentioned. -- Darren Duncan Sean Hunt wrote: On 03/26/2010 04:16 PM, Jason Switzer wrote: Also, this discussion of "trusts" piqued my interest; this sounds like a bad idea. Those of you who have worked extensively with C++ should bemoan "trusts" as much as friend classes. They break encapsulation for special cases, almost encouraging truly hideous object models that ultimately become purely public (painful on a large scale). I can't stress enough that if these are of similar nature, "trusts" should be removed. I'm all ears though if someone knows of a reason why they're more useful than onerous. -Jason "s1n" Switzer Here's the C++ FAQ Lite's answer to that: http://www.parashift.com/c++-faq-lite/friends.html#faq-14.2 I'm not necessarily sure that this applies to Perl 6 too much (I really haven't paid a ton of attention to access control), but I've always considered C++'s friends to be roughly equivalent to Java's package-private in terms of where they fit into one's notion of encapsulation - this is not to say that they are the same thing! Sean Hunt
Re: You never have privacy from your children in Perl 6
On Mar 27, 2010, at 15:43 , Darren Duncan wrote: My own take on 'trusts' is that I consider its main purpose is to let programmers *avoid* contrivances when they want to define something that would otherwise be a single class but is split into multiple classes for better elegance. For example, say you want to define a graph of some kind, and for elegance you have a separate container and node and side classes, even though conceptually these are all integrated parts of a whole. Say in this case your container class has a This sounds like a hackaround for an incomplete implementation of ADTs. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
