Sex, 2008-09-19 às 10:25 -0700, Jon Lang escreveu:
> Daniel Ruoso wrote:
> > In SMOP, it is handled based on the package of the Class, the private
> > storage inside the object is something like
> > $obj.^!private_storage<$!bar>
> > and
> > $ojb.^!private_storage<$!bar>
> Note that this ought o
Daniel Ruoso wrote:
> Jon Lang wrote:
>> Note that this ought only be true of class inheritance; with role
>> composition, there should only be one $!bar in the class, no matter
>> how many roles define it.
>
> er... what does that mean exactly?
Unless something has drastically changed since I las
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
May I pose three more questions?
1. I guess that even using $!A::bar in methods of B is an
access violation, right? I.e. A needs to trust B for that
to be allowed.
Correct.
2. The object has to carry $!A::bar and $!B::bar separate
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
class A
{
has $.foo = "A";
has $!bar = "A";
method blahh()
{
say $.foo ~ $!foo ~ $!bar;
}
}
class B is A
{
has $.foo = "B";
has $!bar = "B";
}
my $a = A.new;
Jon Lang wrote:
Daniel Ruoso wrote:
TSa wrote:
May I pose three more questions?
1. I guess that even using $!A::bar in methods of B is an
access violation, right? I.e. A needs to trust B for that
to be allowed.
Yes
2. The object has to carry $!A::bar and $!B::bar
Daniel Ruoso wrote:
> TSa wrote:
>> May I pose three more questions?
>>
>> 1. I guess that even using $!A::bar in methods of B is an
>> access violation, right? I.e. A needs to trust B for that
>> to be allowed.
>
> Yes
>
>> 2. The object has to carry $!A::bar and $!B::bar separately, right
Sex, 2008-09-19 às 17:49 +0200, TSa escreveu:
> Daniel Ruoso wrote:
> > Qui, 2008-09-18 às 18:11 +0200, TSa escreveu:
> >> Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
> >> without an accessor?
> > Actually, $!B::bar doesn't overwrite $!A::bar... the problem is simply
> > tha
Sex, 2008-09-19 às 17:49 +0200, TSa escreveu:
> Daniel Ruoso wrote:
> > Qui, 2008-09-18 às 18:11 +0200, TSa escreveu:
> >> Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
> >> without an accessor?
> > Actually, $!B::bar doesn't overwrite $!A::bar... the problem is simply
> > tha
HaloO,
Daniel Ruoso wrote:
Qui, 2008-09-18 às 18:11 +0200, TSa escreveu:
Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
without an accessor?
Actually, $!B::bar doesn't overwrite $!A::bar... the problem is simply
that $!A::bar is not visible from inside B, and therefore, t
Qui, 2008-09-18 às 18:11 +0200, TSa escreveu:
> Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
> without an accessor?
Actually, $!B::bar doesn't overwrite $!A::bar... the problem is simply
that $!A::bar is not visible from inside B, and therefore, there's
nothing to be overrid
HaloO,
Carl Mäsak wrote:
I really like all the replies I got to this; thank you Moritz,
Jonathan, TSa, Larry, John and Damian.
It was a pleasure to be useful.
From the feedback I received, I will now do the following:
1. Remove "is rw" from all attributes that aren't supposed to be
writabl
I don't understand why this stuff is confusing; it's not new with Perl
6. There's a long tradition in O-O of distinguishing between the
externally visible accessor and the internal storage - Ruby self.foo
vs @foo, Java this.foo vs setFoo()/getFoo(), etc. In fact the Ruby
case is directly analogous
* Carl Mäsak <[EMAIL PROTECTED]> [2008-09-18 12:20]:
> 2. Start using $!foo consistently in methods, for both read and
>write accesses.
Unless, of course, you want the class-internal use of the
attribute to go through its accessor! Which you are likely
to want for public attributes, and much l
* Damian Conway <[EMAIL PROTECTED]> [2008-09-18 03:30]:
> When thinking about this, it's also important to remember that,
> in Perl 6, not everything with a sigil is automatically
> writeable.
That’s not even new to Perl 6.
$ perl -e's/foo/bar/ for "foo"'
Modification of a read-only value
I really like all the replies I got to this; thank you Moritz,
Jonathan, TSa, Larry, John and Damian.
>From the feedback I received, I will now do the following:
1. Remove "is rw" from all attributes that aren't supposed to be
writable from outside the class.
2. Start using $!foo consistently in
Larry wrote:
You have to have a way of talking about your own attributes *as if*
they were not your own attributes, and $.foo is that way.
When thinking about this, it's also important to remember that, in Perl 6, not
everything with a sigil is automatically writeable. For example:
Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote:
I have come to understand that this is an available possibility, yes.
That doesn't mean I like it. :)
My complaint could be pithily summarized as "those are _my_,
attributes, why can't I write to them?"
// Carl
If the accessor were implemented
On Wed, Sep 17, 2008 at 01:00:07PM +0200, Carl Mäsak wrote:
: Jonathan (>):
: > Why not just assign to $!foo, which is always read/write (since the rw
: > affects whether you get an accessor that is read/write or not - $!foo refers
: > to the underlying storage location; at least, that's how I unde
HaloO,
Carl Mäsak wrote:
My complaint could be pithily summarized as "those are _my_,
attributes, why can't I write to them?"
Perhaps you should change your POV. The correct terminus
technicus for the $.foo twigil variables is 'call the method'
which nicely embeds attribute access into dispatc
Jonathan (>):
> Why not just assign to $!foo, which is always read/write (since the rw
> affects whether you get an accessor that is read/write or not - $!foo refers
> to the underlying storage location; at least, that's how I understand it and
> what I think Rakudo is implementing today).
I have
Moritz Lenz wrote:
Yes, I know that $.stuff actually translates to $( self.stuff ), so
without 'is rw' there is no rw accessor generated - but couldn't we just fake
assignment to '$.foo' to actually affect '$!foo'?
Why not just assign to $!foo, which is always read/write (since the rw
affect
Just to bring some of the IRC discussion to the list...
Carl Mäsak wrote:
> Rakudo and I have a disagreement over this: I expect to be able to
> assign to a $.foo attribute in methods within the class, whereas
> Rakudo demands the "is rw" attribute in order to do that.
>
> We discussed it a bit o
22 matches
Mail list logo
