S05 and S29 may conflict on behavior of $string.match(/pat/)

2008-09-18 Thread Chris Davaz
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

Re: Should $.foo attributes without is rw be writable from within the class

2008-09-18 Thread Carl Mäsak
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

Re: Should $.foo attributes without is rw be writable from within the class

2008-09-18 Thread Aristotle Pagaltzis
* 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

Re: Should $.foo attributes without is rw be writable from within the class

2008-09-18 Thread Aristotle Pagaltzis
* 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

Re: Should $.foo attributes without is rw be writable from within the class

2008-09-18 Thread Mark J. Reed
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

Re: S05 and S29 may conflict on behavior of $string.match(/pat/)

2008-09-18 Thread Larry Wall
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 : :

Re: How to define a new value type?

2008-09-18 Thread TSa
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

Re: Should $.foo attributes without is rw be writable from within the class

2008-09-18 Thread TSa
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

Re: S05 and S29 may conflict on behavior of $string.match(/pat/)

2008-09-18 Thread Chris Davaz
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