Well,
So far there's a 55/45 split for chaining, so I'll release a
preliminary version with:
use accessors qw( foo bar baz ); # same as accessors::chained
use accessors::classic qw( foo bar baz );
use accessors::chained qw( foo bar baz );
The last one will guarantee backw
Damian Conway <[EMAIL PROTECTED]> writes:
> For what it's worth...
>
> Perl 6 classes will autogenerate accessors that return the underlying
> attribute itself as an lvalue:
>
> class DogTag {
> has $.name is public;
> has $.rank is public;
> has $.s
Steve Purkis asked:
Will generated accessors be overridable?
Indeed they will. If the class has an explicitly declared method of the same
name, that method will prevent the accessor from being generated. And, of
course, accessors are just methods, so derived classes can override them in
the nor
On Wednesday, September 17, 2003, at 12:34 pm, Sam Vilain wrote:
[snip!]
Either of these are good IMHO:
$class->set_attribute("value");
$class->attribute = "value";
In both cases, it is 100% clear that the `$class' object it having its
`attribute' member updated.
The first example up there is
On Wed, 17 Sep 2003, Robin Berjon wrote:
> Shevek wrote:
> > On Wed, 17 Sep 2003, Robin Berjon wrote:
> >>sub foo { @_==2 ? shift->{foo} = pop : shift->{foo} }
> >
> > This is semantically different, and therefore not an appropriate answer.
>
> Semantically different from what, and an appropriat
Shevek wrote:
On Wed, 17 Sep 2003, Robin Berjon wrote:
Shevek wrote:
On Wed, 17 Sep 2003, Robin Berjon wrote:
sub foo { @_==2 ? shift->{foo} = pop : shift->{foo} }
This is semantically different, and therefore not an appropriate answer.
Semantically different from what, and an appropriate answer to
On Wednesday, September 17, 2003, at 11:38 am, Mark Fowler wrote:
On Tue, 16 Sep 2003, Steve Purkis wrote:
There are two popular styles of accessor I'd like to support:
# classic:
print "I set foo!" if $obj->foo( $a_value );
# chaining:
$obj->foo( $a_value )
Shevek wrote:
On Wed, 17 Sep 2003, Robin Berjon wrote:
sub foo { @_==2 ? shift->{foo} = pop : shift->{foo} }
This is semantically different, and therefore not an appropriate answer.
Semantically different from what, and an appropriate answer to what? It DTRT.
--
Robin Berjon <[EMAIL PROTECTED]>
Re
Sam Vilain wrote:
>
> Either of these are good IMHO:
>
> $class->set_attribute("value");
> $class->attribute = "value";
The latter I don't like. Although it's very intuitive as a setter, I don't like
having (giving, I really mean) such unfettered access to such things. I like to
check values
On Wed, 17 Sep 2003 11:55, Steve Purkis wrote;
> Hmm, that's very similar in spirit to the 'classic' form.
>
> Will generated accessors be overridable? I can see how 'given' would
> be useful, but what if I wanted to say this:
>
> $grunt.name( "Patton" )
> .
On Wednesday, September 17, 2003, at 10:48 am, Paul Makepeace wrote:
Je 2003-09-17 10:21:50 +0100, Robin Berjon skribis:
sub foo { @_==2 ? shift->{foo} = shift : shift->{foo} }
sub foo { @_==2 ? $_[0]->{foo} = $_[1] : $_[0]->{foo} }
Probably marginally quicker, and doesn't leave that niggly
On Wednesday, September 17, 2003, at 10:08 am, Michel Rodriguez wrote:
On Tue, 16 Sep 2003, Steve Purkis wrote:
On Tuesday, September 16, 2003, at 02:53 pm, Andy Wardley wrote:
On the other hand, I find it quite acceptable to have get_foo()
that returns the foo, and set_foo($new_value) which s
On Wed, 17 Sep 2003, Mark Fowler wrote:
> On Tue, 16 Sep 2003, Steve Purkis wrote:
>
> That having been said, are you aware of Want? If you want to do the above
> you can do something like this:
>
> use Want;
>
> if (want('OBJECT'))
> {
>$self->_set_foo($_[0]);
>retur
On Tuesday, September 16, 2003, at 09:51 pm, Damian Conway wrote:
For what it's worth...
Perl 6 classes will autogenerate accessors that return the underlying
attribute itself as an lvalue:
class DogTag {
has $.name is public;
has $.rank is public;
On Wednesday, September 17, 2003, at 02:50 am, Randal L. Schwartz
wrote:
"Steve" == Steve Purkis <[EMAIL PROTECTED]> writes:
I've seen:
print "Old version of foo was " . $obj->foo( $new_foo );
(gtk, I think), and
print "New version of foo is now " . $obj->foo( $new_foo );
Steve> This is the
On Wednesday, September 17, 2003, at 02:49 am, Randal L. Schwartz
wrote:
"Steve" == Steve Purkis <[EMAIL PROTECTED]> writes:
Steve> Hi all,
Steve> With the help of others, I've been bashing out an 'accessors'
pragma[1]:
Steve> use accessors qw( foo bar baz );
Steve> There are two popular sty
On Tue, 16 Sep 2003, Steve Purkis wrote:
> There are two popular styles of accessor I'd like to support:
>
> # classic:
> print "I set foo!" if $obj->foo( $a_value );
>
> # chaining:
> $obj->foo( $a_value )
> ->bar( $another_value );
Firstly, I prefer proper exce
On Wed, 17 Sep 2003, Robin Berjon wrote:
> David Cantrell wrote:
> > On Wed, Sep 17, 2003 at 11:21:50AM +0200, Robin Berjon wrote:
> >> sub foo { @_==2 ? shift->{foo} = shift : shift->{foo} }
> >
> >^ ^
> > Is the order of evaluation of those two shift()
On Wed, 17 Sep 2003, Robin Berjon wrote:
> Richard Clamp wrote:
> > @_ will still have an element in it after shifting off $self, so the
> > old favourite:
> >
> > sub foo {
> > my $self = shift;
> > if (@_) {
> > $self->{foo} = shift;
> > }
> > $self->{foo}; # or $s
On Wed, Sep 17, 2003 at 11:58:27AM +0200, Robin Berjon wrote:
> Nicholas Clark wrote:
> > There's just been a long thread about this on p5p.
> > I think that "not really" is the current answer, and it's proved impossible
> > to cleanly write down what the order of evaluation is.
> > In the above li
David Wright wrote:
sub foo { @_==2 ? shift->{foo} = shift : shift->{foo} }
Why bother shifting at all then?
sub foo { @_==2 ? $_[0]->{foo} = $_[1] : $_[0]->{foo} }
Because it's cuter and easier to type.
Oh, and it's nigh impossible to tell them apart:
===
use Benchmark qw(timethese cmpthese);
On Wed, 17 Sep 2003, Paul Makepeace wrote:
> Je 2003-09-17 10:21:50 +0100, Robin Berjon skribis:
> > sub foo { @_==2 ? shift->{foo} = shift : shift->{foo} }
>
>sub foo { @_==2 ? $_[0]->{foo} = $_[1] : $_[0]->{foo} }
>
> Probably marginally quicker, and doesn't leave that niggly feeling about
Nicholas Clark wrote:
There's just been a long thread about this on p5p.
I think that "not really" is the current answer, and it's proved impossible
to cleanly write down what the order of evaluation is.
In the above line, they evaluate right to left, because the RHS of the
assignment is being eval
David Cantrell wrote:
On Wed, Sep 17, 2003 at 11:21:50AM +0200, Robin Berjon wrote:
sub foo { @_==2 ? shift->{foo} = shift : shift->{foo} }
^ ^
Is the order of evaluation of those two shift()s guaranteed?
I thought about that as I was writing it, I normally
Je 2003-09-17 10:21:50 +0100, Robin Berjon skribis:
> sub foo { @_==2 ? shift->{foo} = shift : shift->{foo} }
sub foo { @_==2 ? $_[0]->{foo} = $_[1] : $_[0]->{foo} }
Probably marginally quicker, and doesn't leave that niggly feeling about
which shift might be evaluated in what order in a fut
> > @_ will still have an element in it after shifting off $self, so the
> > old favourite:
> >
> > sub foo {
> > my $self = shift;
> > if (@_) {
> > $self->{foo} = shift;
> > }
> > $self->{foo}; # or $self;
> > }
> >
> > Will still have something to assign.
>
> While
On Wed, Sep 17, 2003 at 10:40:06AM +0100, David Cantrell wrote:
> On Wed, Sep 17, 2003 at 11:21:50AM +0200, Robin Berjon wrote:
>
> >sub foo { @_==2 ? shift->{foo} = shift : shift->{foo} }
>^ ^
> Is the order of evaluation of those two shift()s guarante
On Wed, Sep 17, 2003 at 11:21:50AM +0200, Robin Berjon wrote:
>sub foo { @_==2 ? shift->{foo} = shift : shift->{foo} }
^ ^
Is the order of evaluation of those two shift()s guaranteed?
--
Lord Protector David Cantrell | http://www.cantrell.org.uk/davi
At 10:00 +0100 2003/09/17, Richard Clamp wrote:
>
How? I can't see how that would work..
@_ will still have an element in it after shifting off $self, so the
gaaah.
ok, I can see that.
--
.tom
Richard Clamp wrote:
@_ will still have an element in it after shifting off $self, so the
old favourite:
sub foo {
my $self = shift;
if (@_) {
$self->{foo} = shift;
}
$self->{foo}; # or $self;
}
Will still have something to assign.
While I'm not a golfer and am usuall
On Tue, 16 Sep 2003, Steve Purkis wrote:
> On Tuesday, September 16, 2003, at 02:53 pm, Andy Wardley wrote:
> > On the other hand, I find it quite acceptable to have get_foo()
> > that returns the foo, and set_foo($new_value) which sets the
> > new value for foo and returns the object. In this
At 17:59 +0100 2003/09/16, Steve Purkis wrote:
Secondly, with the current implementation an 'undef' argument will
trigger a set for both 'classic' and 'chained' accessors:
$book->author($a); # still sets when $a = undef
How? I can't see how that would work..
--
.tom
On Wed, Sep 17, 2003 at 09:47:43AM +0100, Tom Insam wrote:
> At 17:59 +0100 2003/09/16, Steve Purkis wrote:
> >
> >Secondly, with the current implementation an 'undef' argument will
> >trigger a set for both 'classic' and 'chained' accessors:
> >
> > $book->author($a); # still sets when $a = u
> "Steve" == Steve Purkis <[EMAIL PROTECTED]> writes:
>> I've seen:
>>
>> print "Old version of foo was " . $obj->foo( $new_foo );
>>
>> (gtk, I think), and
>>
>> print "New version of foo is now " . $obj->foo( $new_foo );
Steve> This is the 'classic' style I had in mind.
Then your naming
> "Steve" == Steve Purkis <[EMAIL PROTECTED]> writes:
Steve> Hi all,
Steve> With the help of others, I've been bashing out an 'accessors' pragma[1]:
Steve> use accessors qw( foo bar baz );
Steve> There are two popular styles of accessor I'd like to support:
Steve> # classic:
Steve> # cha
For what it's worth...
Perl 6 classes will autogenerate accessors that return the underlying
attribute itself as an lvalue:
class DogTag {
has $.name is public;
has $.rank is public;
has $.serial is readonly;
has @.medals is
On Tuesday, Sep 16, 2003, at 13:09 Europe/London, Steve Purkis wrote:
[snip]
If you have a preference here, let me know.
[snip]
I quite like chaining myself - but then I like Smalltalk too :-)
Adrian
Shevek wrote:
On Tue, 16 Sep 2003, David Cantrell wrote:
Paul Makepeace wrote:
WTF is that?! If I saw this in a forest I'd shoot it first, assuming it
was more likely going to kill me than not.
Something which makes perfect sense when read in conjunction with the
documentation. What, exactly, do
On Tue, 16 Sep 2003, David Cantrell wrote:
> Paul Makepeace wrote:
> > Je 2003-09-16 15:37:49 +0100, David Cantrell skribis:
> >>return 0->reason(ERR_BAD_PARAM)->details('foo')
> >> unless($params{foo} && $params{foo}->isa('Foo'));
> > WTF is that?! If I saw this in a forest I'd shoot it first, a
Paul Makepeace wrote:
Je 2003-09-16 15:37:49 +0100, David Cantrell skribis:
return 0->reason(ERR_BAD_PARAM)->details('foo')
unless($params{foo} && $params{foo}->isa('Foo'));
WTF is that?! If I saw this in a forest I'd shoot it first, assuming it
was more likely going to kill me than not.
Something
Shevek wrote:
On Tue, 16 Sep 2003, David Cantrell wrote:
I see similar method chaining in Java.
poing = foo.convert_to_bar().do_stuff_to_object().convert_to_string();
In this case, I don't see that foo.convert_to_bar() is returning foo. I
don't claim that method chaining is wrong. I claim that met
On Tuesday, September 16, 2003, at 02:53 pm, Andy Wardley wrote:
Steve Purkis wrote:
# chaining:
$obj->foo( $a_value )
->bar( $another_value );
I recognise how useful this can be but I'm not a fan of it.
IMHO, the foo() method of an object should return the foo of
the
On Tue, 16 Sep 2003, Paul Makepeace wrote:
> Je 2003-09-16 15:37:49 +0100, David Cantrell skribis:
> > return 0->reason(ERR_BAD_PARAM)->details('foo')
> > unless($params{foo} && $params{foo}->isa('Foo'));
>
> WTF is that?! If I saw this in a forest I'd shoot it first, assuming it
> was more lik
Je 2003-09-16 15:37:49 +0100, David Cantrell skribis:
> return 0->reason(ERR_BAD_PARAM)->details('foo')
> unless($params{foo} && $params{foo}->isa('Foo'));
WTF is that?! If I saw this in a forest I'd shoot it first, assuming it
was more likely going to kill me than not.
P
--
Paul Makepeace ..
On Tuesday, September 16, 2003, at 03:37 pm, David Cantrell wrote:
On Tue, Sep 16, 2003 at 02:18:57PM +0100, Steve Purkis wrote:
On Tuesday, September 16, 2003, at 01:27 pm, Tom Insam wrote:
Having said that, I like chaining.
Duly noted.
So do I. I have recently fallen in love with Scalar::Prop
On Tue, 16 Sep 2003, David Cantrell wrote:
> On Tue, Sep 16, 2003 at 02:44:25PM +0100, Shevek wrote:
>
> > This whole chained accessors thing is a definite perl-ism and will do you
> > no favours with people for whom Perl is not a primary language.
>
> I see similar method chaining in Java.
>
Je 2003-09-16 15:40:45 +0100, David Cantrell skribis:
> On Tue, Sep 16, 2003 at 02:44:25PM +0100, Shevek wrote:
>
> > This whole chained accessors thing is a definite perl-ism and will do you
> > no favours with people for whom Perl is not a primary language.
>
> I see similar method chaining in
Steve Purkis wrote:
> # chaining:
> $obj->foo( $a_value )
> ->bar( $another_value );
I recognise how useful this can be but I'm not a fan of it.
IMHO, the foo() method of an object should return the foo of
the object. It shouldn't magically switch to returning the
object i
On Tuesday, September 16, 2003, at 02:44 pm, Shevek wrote:
On Tue, 16 Sep 2003, Steve Purkis wrote:
Hi all,
With the help of others, I've been bashing out an 'accessors'
pragma[1]:
use accessors qw( foo bar baz );
There are two popular styles of accessor I'd like to support:
# clas
On Tue, Sep 16, 2003 at 02:44:25PM +0100, Shevek wrote:
> This whole chained accessors thing is a definite perl-ism and will do you
> no favours with people for whom Perl is not a primary language.
I see similar method chaining in Java.
poing = foo.convert_to_bar().do_stuff_to_object().convert_
Shevek wrote:
This whole chained accessors thing is a definite perl-ism and will do you
no favours with people for whom Perl is not a primary language.
Possible return values for write-accessors:
true/false
undef/error message
the previous value
the new value
[I would never have considered the o
On Tue, Sep 16, 2003 at 02:18:57PM +0100, Steve Purkis wrote:
> On Tuesday, September 16, 2003, at 01:27 pm, Tom Insam wrote:
> > Having said that, I like chaining.
> Duly noted.
So do I. I have recently fallen in love with Scalar::Properties (thanks
Marcel!) and do stuff like ...
return 0->rea
On Tue, 16 Sep 2003, Steve Purkis wrote:
> Hi all,
>
> With the help of others, I've been bashing out an 'accessors' pragma[1]:
>
> use accessors qw( foo bar baz );
>
> There are two popular styles of accessor I'd like to support:
>
> # classic:
> print "I set foo!" if $obj->
On Tuesday, September 16, 2003, at 01:27 pm, Tom Insam wrote:
At 13:09 +0100 2003/09/16, Steve Purkis wrote:
Hi all,
With the help of others, I've been bashing out an 'accessors'
pragma[1]:
use accessors qw( foo bar baz );
There are two popular styles of accessor I'd like to support:
At 13:09 +0100 2003/09/16, Steve Purkis wrote:
Hi all,
With the help of others, I've been bashing out an 'accessors' pragma[1]:
use accessors qw( foo bar baz );
There are two popular styles of accessor I'd like to support:
# classic:
print "I set foo!" if $obj->foo( $a_value );
Hi all,
With the help of others, I've been bashing out an 'accessors' pragma[1]:
use accessors qw( foo bar baz );
There are two popular styles of accessor I'd like to support:
# classic:
print "I set foo!" if $obj->foo( $a_value );
# chaining:
$obj->foo( $a_valu
56 matches
Mail list logo
