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,
Moritz Lenz wrote:
When you read carefully through S29 you'll notice that most methods in
immutable classes (like Str, List, Int) only return modified copies,
even if they mutate the string in Perl 5.
Great!
(There are some exceptions like Str.substr, which explicitly 'is rw',
and
TSa wrote:
The 'is rw' is on the method but I guess it is foreseen that the
result is stored in $string without preserving the identity of the
string?
No. It means that the Str object has to get hold of the container in
which it is stored, and store a modified copy in it. If that fails (for
HaloO,
Moritz Lenz wrote:
TSa wrote:
The 'is rw' is on the method but I guess it is foreseen that the
result is stored in $string without preserving the identity of the
string?
No. It means that the Str object has to get hold of the container in
which it is stored, and store a modified copy
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 Mon, Sep 15, 2008 at 12:16:22PM +0200, Moritz Lenz wrote:
: Chris Davaz wrote:
: I'm not sure if it's anywhere in the specs, but I was expecting to be able
: to do this:
:
: .say for =$in unless $foo;
:
: to quote http://perlcabal.org/syn/S04.html#Loop_statements
:
: :Looping statement
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
On Wed, Sep 17, 2008 at 08:08:47PM +0200, Reini Urban wrote:
http://www.parrotcode.org/release/devel still points to 0.7.0
I sent the appropriate patch to the webmaster, but it hasn't
been applied yet (and I lack a commit bit for the parrotcode.org site).
Once that's applied, the url should be
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
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
Reading the description there I wonder how this is supposed to work.
I don't think S29 is in any shape as a serious design specification.
Maybe you should not design it that way. Maybe the left-hand-side is
as ref so it can change the
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
Sorry, I don't understand why you say 'no' and then explain that the
resulting new string is stored in the container. The only container
that could be affected by this is $string in the example. The way for
a method to get access to the
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:
14 matches
Mail list logo