S05 and S29 may conflict on behavior of $string.match(/pat/)
I'm trying to pin down what $string.match(/pat/) should be returning. From S05: Under Return values from match objects A match always returns a Match object... From S29: Under the definition of Str.comb Saying $string.comb(/pat/, $n) is equivalent to $string.match(rx:global:x(0..$n):c/pat/) [ ...and later... ] If there are captures in the pattern, a list of Match objects (one per match) is returned instead of strings. Which implies that $string.match(/pat/) should indeed return a List of Str and $string.match(/pat_with_groups/) should return a List of Match. I expected the S29 definition when first approaching $string.match I feel it is more intuitive than what happens with S05. Could someone clarify what the behavior should be? Best Regards, -Chris Davaz
Re: Should $.foo attributes without is rw be writable from within the class
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 methods, for both read and write accesses. It remains to be seen whether the greater understanding you have given me about the inner workings of Perl 6 classes will make this system bearable. :) I hope it will. // Carl
Re: Should $.foo attributes without is rw be writable from within the class
* 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 attempted at -e line 1.
--
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: Should $.foo attributes without is rw be writable from within the class
* 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 likely for class- private ones. So Perl 6 defaults the right thing here, it would seem. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Should $.foo attributes without is rw be writable from within the class
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: Perl 6 Ruby has $.foo attr_reader :foo has $.foo is rw attr_accessor :foo $.foo
Re: S05 and S29 may conflict on behavior of $string.match(/pat/)
On Thu, Sep 18, 2008 at 06:11:45PM +0800, Chris Davaz wrote: : I'm trying to pin down what $string.match(/pat/) should be returning. : : From S05: : : Under Return values from match objects : A match always returns a Match object... : : From S29: : : Under the definition of Str.comb : : Saying : : $string.comb(/pat/, $n) : : is equivalent to : : $string.match(rx:global:x(0..$n):c/pat/) : : [ ...and later... ] : : If there are captures in the pattern, a list of Match objects (one : per match) is returned instead of strings. : : Which implies that $string.match(/pat/) should indeed return a List of : Str and $string.match(/pat_with_groups/) should return a List of : Match. : : I expected the S29 definition when first approaching $string.match I : feel it is more intuitive than what happens with S05. Could someone : clarify what the behavior should be? S05 is using a different definition of match. In S05 it means more like one low-level run of the regex engine rather than one high-level call to the .match method. In other words, the .match method can do multiple matches. Larry
Re: How to define a new value type?
HaloO, John M. Dlugosz wrote: TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote: Is it generally foreseen that an object knows about the containers it is stored in? Yes. But it is not generally the case that this is the same container as the caller is holding. Detailed specifications of the meaning of 'read-only', 'rw', 'copy', and 'ref' and the binding semantics thereof need to address this, and address the concerns of efficient implementations. I meant the general 1:n relation of value to containers not the relation of outer and inner containers in sub calls. I think that back refs from the value to all containers is cumbersome and of little practical value if the semantics of the language don't require it. E.g. if the deletion of values were possible then all containers holding the value need to be nulled. The back refs need to be updated when a container receives a new value. It has to detach from the former value and attach to the new one. So again the question: are back refs from the value to the containers required to implement Perl 6? I guess not. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Should $.foo attributes without is rw be writable from within the class
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 from outside the class.
2. Start using $!foo consistently in methods, for both read and write accesses.
From a best practice POV consider
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 = B.new;
say $a.blahh; # prints AAA
say $b.blahh; # prints BAA, right?
Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
without an accessor? And of course the example shows that $!foo in
blahh is not derivation friendly. Or am I getting things wrong and
there can be only one $!foo and $!bar in the namespace of the objects
created from A and B? That is the declarations in B are superfluous
if not outright wrong? Well, or they only affect the generated
constructor and the storage location is shared? The latter would
nicely contrast them to non twigil attributes in the form 'has $foo'.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: S05 and S29 may conflict on behavior of $string.match(/pat/)
Thanks for clarifying however I'm still unsure what a Perl 6 user should expect to get back from running $string.match(/pat/). This is the one high-level call to the .match method yes? So it should be returning a List of Str (or List of Match in case of capture groups), is this correct? I ask because in the current Rakudo implementation it returns the Match object (what I would expect from the one low-level run of the regex engine). Best Regards, -Chris On Thu, Sep 18, 2008 at 11:52 PM, Larry Wall [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 06:11:45PM +0800, Chris Davaz wrote: : I'm trying to pin down what $string.match(/pat/) should be returning. : : From S05: : : Under Return values from match objects : A match always returns a Match object... : : From S29: : : Under the definition of Str.comb : : Saying : : $string.comb(/pat/, $n) : : is equivalent to : : $string.match(rx:global:x(0..$n):c/pat/) : : [ ...and later... ] : : If there are captures in the pattern, a list of Match objects (one : per match) is returned instead of strings. : : Which implies that $string.match(/pat/) should indeed return a List of : Str and $string.match(/pat_with_groups/) should return a List of : Match. : : I expected the S29 definition when first approaching $string.match I : feel it is more intuitive than what happens with S05. Could someone : clarify what the behavior should be? S05 is using a different definition of match. In S05 it means more like one low-level run of the regex engine rather than one high-level call to the .match method. In other words, the .match method can do multiple matches. Larry
