Martin D Kealey wrote:
On Mar 27, 2010, at 15:43 , Darren Duncan wrote:
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,
On Sat, 27 Mar 2010, Brandon S. Allbery KF8NH wrote:
This sounds like a hackaround for an
> On Mar 27, 2010, at 15:43 , Darren Duncan wrote:
> > 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,
On Sat, 27 Mar 2010, Brandon S. Allbery KF8NH wrote:
> This sounds like a hackaround for an incomplete impl
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 examp
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
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
On Fri, Mar 26, 2010 at 7:16 AM, Carl Mäsak wrote:
> You're using it wrong. You need to put 'trusts B;' in A in order for B to
> > see A's privates. I hope it is obvious why this is the case. -- Darren
> > Duncan
>
> Aye, my mistake. Apparently the syntax I used to try to get at the
> private a
Carl (>), Darren (>>):
>> I didn't get it to trust me, though:
>>
>> pugs: class A { has $!foo }; class B { trusts A; method bar(A
>> $a) { say $a!foo } }; B.new.bar(A.new(:bar(42)))
>> pugs: OUTPUT«»
>>
>> Either it bitrotted or I'm using it wrong.
>
> You're using it wrong. You need to put 't
Carl Mäsak wrote:
Carl (>>), Darren (>):
[...] and the
'trusts' keyword hasn't been realized in any Perl 6 implementation so
far.
I seem to recall that Pugs did support 'trusts' a few years ago, and that I
used it. But I could be wrong. -- Darren Duncan
I stand corrected. A quick search thro
Carl (>>), Darren (>):
>> [...] and the
>> 'trusts' keyword hasn't been realized in any Perl 6 implementation so
>> far.
>
> I seem to recall that Pugs did support 'trusts' a few years ago, and that I
> used it. But I could be wrong. -- Darren Duncan
I stand corrected. A quick search through the
Carl Mäsak wrote:
Carl (), Moritz (>>>), Carl (>>), Moritz (>):
um, so 'protected' is when the deriving classes can see the attribute?
yup
that's what 'private' means in Perl 6.
That's wrong. Perl 6's "private" is like Java's "private" - subclasses
can't see it.
It's just Rakudo being le
Carl (), Moritz (>>>), Carl (>>), Moritz (>):
um, so 'protected' is when the deriving classes can see the
attribute?
yup
that's what 'private' means in Perl 6.
>>>
>>> That's wrong. Perl 6's "private" is like Java's "private" - subclasses
>>> can't see it.
>>> It's just
Am Dienstag, den 23.03.2010, 20:06 +0100 schrieb Moritz Lenz:
>
> Carl Mäsak wrote:
> > Carl (>>), Moritz (>):
> >>> um, so 'protected' is when the deriving classes can see the
> >>> attribute?
> >>> yup
> >>> that's what 'private' means in Perl 6.
> >>
> >> That's wrong. Perl 6's "private" i
Em Ter, 2010-03-23 às 20:53 +0100, Moritz Lenz escreveu:
> unless you count 'trusts'
> traits, which are specific to single classes, not groups of subclasses
Yes, that was what I meant...
daniel
Daniel Ruoso wrote:
> Em Ter, 2010-03-23 às 19:41 +0100, Carl Mäsak escreveu:
>> um, so 'protected' is when the deriving classes can see the
>> attribute?
>> yup
>> that's what 'private' means in Perl 6.
>> what? so there's only really 'public' and 'protected', but no
>> 'private'?
>> basicall
Em Ter, 2010-03-23 às 19:41 +0100, Carl Mäsak escreveu:
> um, so 'protected' is when the deriving classes can see the
> attribute?
> yup
> that's what 'private' means in Perl 6.
> what? so there's only really 'public' and 'protected', but no
> 'private'?
> basically, yes. although 'protected'
Carl Mäsak wrote:
> Carl (>>), Moritz (>):
>>> um, so 'protected' is when the deriving classes can see the
>>> attribute?
>>> yup
>>> that's what 'private' means in Perl 6.
>>
>> That's wrong. Perl 6's "private" is like Java's "private" - subclasses
>> can't see it.
>> It's just Rakudo being
Carl (>>), Moritz (>):
>> um, so 'protected' is when the deriving classes can see the
>> attribute?
>> yup
>> that's what 'private' means in Perl 6.
>
> That's wrong. Perl 6's "private" is like Java's "private" - subclasses
> can't see it.
> It's just Rakudo being leaky at the moment, not a fal
Carl Mäsak wrote:
> um, so 'protected' is when the deriving classes can see the attribute?
> yup
> that's what 'private' means in Perl 6.
That's wrong. Perl 6's "private" is like Java's "private" - subclasses
can't see it.
It's just Rakudo being leaky at the moment, not a fallacy of the Perl 6
Wanting to run the recent class-attribute discussion[0] through the
neural net of my friend, I described to him in detail how the current
system with attributes works. He's kind of a Java guy, and though he
liked the twigil distinction between private and public, he asked how
to produce a 'protecte
19 matches
Mail list logo
