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_storageA::$!bar
and
$ojb.^!private_storageB::$!bar
Note that this ought only be
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
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,
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
that $!A::bar
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
that $!A::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?
Yes
3.
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
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;
my $b
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
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 last
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
* 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
* 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 less
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
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
writable
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 on
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
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 come
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 dispatch
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
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
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:
22 matches
Mail list logo
