Re: [OT] accessors pragma
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 $.serial is readonly;
has @.medals is public;
submethod BUILD ($id) { $.serial = $id }
method title () { return $.rank $.name }
}
my $grunt = DogTag.new(71625371);
$grunt.name = Pyle;
$grunt.rank = Private;
print $grunt.title ($grunt.serial)\n;
And Perl 6 supports chaining of accessors using $_ and the unary dot
operator, not return values:
given $grunt {
.name = Patton;
.rank = General;
push .medals, Purple heart;
}
The more I play with Smalltalk, the more I like it:
grunt
setName: 'Patton';
setRank: #General;
addMedal: Purple heart.
For those who don't know Smalltalk, the semicolon says 'send the next
message to the same object' and the full stop terminates the
expression.
Then, just as I'm lost in admiration for it, it goes and does this to
me:
2 + 3 * 2 - 10
And the weird thing is, within a Smalltalk context I don't hate it
(much) because it's apparent that it does that because that's how it
handles *every* binary message.
Re: [OT] accessors pragma
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 backwards compat in case I get enough feedback to warrant changing the default. Ta for all the replies, -Steve
Re: [OT] accessors pragma
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 = undef
How? I can't see how that would work..
@_ 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.
--
Richard Clamp [EMAIL PROTECTED]
Re: [OT] accessors pragma
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
Re: [OT] accessors pragma
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 case, the action is explicit in the method name. # this is when chaining is good, IMHO $obj-set_foo(10)-set_bar(20)-set_baz(30); Question is: what style should be the default? I'm not looking for a debate here, [...] But you bring up some points I've gotta answer -- first off, 'set_' 'get_' don't seem to be too popular (laziness?) so unless people prove me wrong here, they're out for accessors.pm. [1] [...] [1] As a complete aside, I don't think 'get_' and 'set_' are bad ideas. There's no reason reason someone couldn't write 'accessors::setget', or 'getters' and 'setters' pragmas. Michael Schwern recently pointed me to Ruby's 'attr_reader' and 'attr_writer' shortcuts - see http://www.rubycentral.com/book/tut_classes.html +1 for getter/setters then. I resisted posting about it for fear of starting a debate, but apparently Andy couldn't help himself... ;--) I often have getters, or things that really look like getters at least, that are much happier when passed parameters. You can't do that with the usual Perl idiom of a single method. lvalues can be a solution, but do not work in all cases. -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: [OT] accessors pragma
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 usually all for readable code, that has to be too
much code for just an accessor :)
sub foo { @_==2 ? shift-{foo} = shift : shift-{foo} }
Assuming you don't return the object.
--
Robin Berjon [EMAIL PROTECTED]
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: [OT] accessors pragma
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
Re: [OT] accessors pragma
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/david
Norton Wipe Info uses hexadecimal values to wipe files. This
provides more security than wiping with decimal values.
-- from the manual of Norton Systemworks 2002, pg 160
Re: [OT] accessors pragma
@_ 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 usually all for readable code, that has to be too
much code for just an accessor :)
sub foo { @_==2 ? shift-{foo} = shift : shift-{foo} }
Why bother shifting at all then?
sub foo { @_==2 ? $_[0]-{foo} = $_[1] : $_[0]-{foo} }
dave
Re: [OT] accessors pragma
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 future version of
perl, etc, etc.
Paul
--
Paul Makepeace ... http://paulm.com/
If lawnmovers have souls, then we should sit very quietly until it
passes.
-- http://paulm.com/toys/surrealism/
Re: [OT] accessors pragma
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 use the $_[N] form. And in
fact, it doesn't work since (now that coffee has settled in) it seems logical
that the rhs gets evaluated before its assignment to the lhs, without which
chained assignments wouldn't work.
Ah well.
sub foo { @_==2 ? shift-{foo} = pop : shift-{foo} }
:)
--
Robin Berjon [EMAIL PROTECTED]
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: [OT] accessors pragma
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 evaluated first: (snip) Fun and games about evaluation order appeared with assigning to hash slices and array slices (for example) For simple assignments though, isn't it a necessity that it has to go RTL? $a = 1; $b = 2; $c = 3; $a = $b = $c; This sets $a to 3. If evaluation didn't go RTL, $a would be set to 2. (mmm. there is something wrong here. At this rate, we'll outdo Israel.pm on the number of perl related messages) Quick, let's move this discussion over to their list ;) -- Robin Berjon [EMAIL PROTECTED] Research Scientist, Expway http://expway.com/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: [OT] accessors pragma
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
which shift might be evaluated in what order in a future version of
perl, etc, etc.
Still Perl-related, sorry...
Has there ever been a proposal to alias $0, $1... to $_[0], $_[1]... at
the beginning of a sub? That would be convenient for that kind of quick
convenience method/function (not to mention that it would improve golf
scores).
--
Michel Rodriguez
Perl amp; XML
http://www.xmltwig.com
Re: [OT] accessors pragma
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);
my $bar = bless { foo = 'one' };
sub foo1 { @_==2 ? shift-{foo} = pop : shift-{foo} }
sub foo2 { @_==2 ? $_[0]-{foo} = $_[1] : $_[0]-{foo} }
my $t = timethese( 10_000_000,
{
'shift' = sub { $bar-foo1; $bar-foo1('two'); },
'array' = sub { $bar-foo2; $bar-foo2('two'); },
});
cmpthese($t);
===
Benchmark:
timing 1000 iterations of
array, shift...
array: 26 wallclock secs (27.64 usr + 0.01 sys = 27.65 CPU) @ 361598.26/s
(n=1000)
shift: 27 wallclock secs (27.89 usr + 0.02 sys = 27.91 CPU) @ 358333.03/s
(n=1000)
Rate shift array
shift 358333/s-- -1%
array 361598/s1%--
--
Robin Berjon [EMAIL PROTECTED]
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: [OT] accessors pragma
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 line, they evaluate right to left, because the RHS of the assignment is being evaluated first: (snip) Fun and games about evaluation order appeared with assigning to hash slices and array slices (for example) For simple assignments though, isn't it a necessity that it has to go RTL? $a = 1; $b = 2; $c = 3; $a = $b = $c; This sets $a to 3. If evaluation didn't go RTL, $a would be set to 2. I think we're talking cross purposes. The associativity of = is RTL, ie $a = $b = $c is $a = ($b = $c); The order of evaluation question is about what happens when $b and $c are expressions instead of simple scalars. Nicholas Clark
Re: [OT] accessors pragma
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 $self;
}
Will still have something to assign.
While I'm not a golfer and am usually all for readable code, that has to be too
much code for just an accessor :)
sub foo { @_==2 ? shift-{foo} = shift : shift-{foo} }
Assuming you don't return the object.
Your first case:
shift-{foo} = shift
In C, this is undefined behaviour, since you read and write twice to the
same memory location without a sequence point.
In LPC, the other bytecoded system I use, it computes rvalues before
lvalues, therefore this would fail.
In Perl, this does what? And is the behaviour guaranteed in nthe future?
Basically... No.
S.
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: [OT] accessors pragma
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()s guaranteed?
I thought about that as I was writing it, I normally use the $_[N] form. And in
fact, it doesn't work since (now that coffee has settled in) it seems logical
that the rhs gets evaluated before its assignment to the lhs, without which
chained assignments wouldn't work.
Ah well.
sub foo { @_==2 ? shift-{foo} = pop : shift-{foo} }
This is semantically different, and therefore not an appropriate answer.
S.
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: [OT] accessors pragma
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 exceptions when something goes wrong. They make
more sense than checking the return value of every returned value.
That having been said, are you aware of Want? If you want to do the above
you can do something like this:
use Want;
sub foo
{
my $self = shift;
return $self-_get_foo() unless @_;
if (want('OBJECT'))
{
$self-_set_foo($_[0]);
return $self
}
else
{
return $self-_set_foo($_[0]);
}
}
(assuming _get_foo gets the attribute, and _set_foo sets the attribute if
it can and returns false if it can't)
(warning, untested code)
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};
Re: [OT] accessors pragma
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 styles of accessor I'd like to support: Steve # classic: Steve # chaining: Don't forget: # previous value (ala umask/select) # success/fail condition Yeah, Shevek pointed those and others out - the reason I've discounted them is down to popularity. Again, there's no reason accessors.pm couldn't be extended to support them, but feature creep is on the list of things to avoid so they'll be out by default. -Steve
Re: [OT] accessors pragma
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 'classic' style I had in mind. Then your naming is odd. I thought classic returned $new_foo, not $old_foo. Huh? It does return $new_foo. -Steve
Re: [OT] accessors pragma
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]);
return $self
}
This is usually the point where performance hits the deck and Perl goes by
the board. It's very nice indeed for hello-world sites with only a few
thousand rows, but deployment rapidly brings with it 100,000 rows, and
suddenly this package which we all tested so thoroughly falls on its arse.
I'm sure we've all met this before somewhere in a profiler.
S.
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: [OT] accessors pragma
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 sets the new value for foo and returns the object. In this case, the action is explicit in the method name. # this is when chaining is good, IMHO $obj-set_foo(10)-set_bar(20)-set_baz(30); Question is: what style should be the default? I'm not looking for a debate here, [...] But you bring up some points I've gotta answer -- first off, 'set_' 'get_' don't seem to be too popular (laziness?) so unless people prove me wrong here, they're out for accessors.pm. [1] [...] [1] As a complete aside, I don't think 'get_' and 'set_' are bad ideas. There's no reason reason someone couldn't write 'accessors::setget', or 'getters' and 'setters' pragmas. Michael Schwern recently pointed me to Ruby's 'attr_reader' and 'attr_writer' shortcuts - see http://www.rubycentral.com/book/tut_classes.html +1 for getter/setters then. I resisted posting about it for fear of starting a debate, but apparently Andy couldn't help himself... ;--) Yeah.. tsk tsk ;-) But seriously, it's a good thing to know - it means there may actually be some use in writing something like: use getters qw( foo bar baz ); use setters qw( foo bar baz ); or perhaps: use accessors::get qw( foo bar baz ); use accessors::set qw( foo bar baz ); use accessors::get_set qw( foo bar baz ); Depending on people's preference. And after another debate on what style of methods to generate :) the majority of Perl coders may be appeased. But again, that's not something for accessors.pm. Have you looked at Class::Accessor and related? -Steve
Re: [OT] accessors pragma
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 feeling
about
which shift might be evaluated in what order in a future version of
perl, etc, etc.
Cool, that's faster than the generated subs I'd come up with.
-Steve
Re: [OT] accessors pragma
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 ) .rank( General ) .add_medal( Purple heart ); I just don't understand this. What practical problem does this arrangement solve? I think it's highly counterintuitive and wasteful of useful spaces for return values. This is 10 times clearer: $grunt.set(name = Patton, rank = General); $grunt.add_medal(Purple heart); No confusion, no scope for something going wrong when someone doesn't return the original object in an accessor. Also, I really think that methods which set values of an attribute, rather than performing some kind of index lookup, ie my $attribute = $class-attribute(cheese); It's fairly clear that you're fetching a value; in this case, Foo is giving more information to the accessor. However, what does this do? $class-attribute(price); Does it set, or get (and ignore)? 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. Do have a look at the accessors generated by Class::Tangram objects, I've put a lot of thought into the way code looks when you use the default accessors. I know that the interface to the module itself is due for a fairly major overhaul, but try to look past that :). -- Sam Vilain, [EMAIL PROTECTED] This is an object-oriented system. If we change anything, the users object.
Re: [OT] accessors pragma
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]
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: [OT] accessors pragma
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 )
-bar( $another_value );
Firstly, I prefer proper exceptions when something goes wrong. They
make
more sense than checking the return value of every returned value.
True - I tend to use die() or Error.pm myself. But the first example
is misleading in that context, Tom wrote something more clear:
print New version of foo is now . $obj-foo( $new_foo );
That having been said, are you aware of Want? If you want to do the
above
you can do something like this:
use Want;
sub foo
{
my $self = shift;
return $self-_get_foo() unless @_;
if (want('OBJECT'))
{
$self-_set_foo($_[0]);
return $self
}
else
{
return $self-_set_foo($_[0]);
}
}
(assuming _get_foo gets the attribute, and _set_foo sets the attribute
if
it can and returns false if it can't)
Cool idea, but I'd be reluctant to do something like that for
performance reasons alone. I'd also like to keep the code as simple as
possible -- having 2 extra method calls and another dependency is too
much creep for me. Again, no reason it couldn't be done in something
like 'accessors::want'...
-Steve
Re: [OT] accessors pragma
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 what? It DTRT.
As someone who uses closures a lot, and tends to have a lot of random
things floating around in the tail end of @_, using the last element of @_
is very different to using the first element.
It's different from the buggy version that due to execution order inverted the
first and second. However, since it tests that there are exactly two items in
@_, if there are things floating around it'll revert to a get.
* darobin still doesn't see the problem, must be thick today
--
Robin Berjon [EMAIL PROTECTED]
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: [OT] accessors pragma
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 what? It DTRT.
As someone who uses closures a lot, and tends to have a lot of random
things floating around in the tail end of @_, using the last element of @_
is very different to using the first element.
S.
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: [OT] accessors pragma
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 actually quite similar to Andy Wardley's. If you're willing to take it a step further and add in method chaining, you get the same thing: print $obj-set_foo(value) -get_foo(value); Though from the Class::Tangram docs, it looks like you prefer to drop the 'get_'. Do have a look at the accessors generated by Class::Tangram objects, I've put a lot of thought into the way code looks when you use the default accessors. I know that the interface to the module itself is due for a fairly major overhaul, but try to look past that :). Just had a glance and the interface looks good. But then, it does more than accessors.pm ever will because it's not meant to replace well thought out class generators. It'd be cool if they got integrated into the various Class::* modules, but my main goal is to create something anyone can just slap in to generate accessors easily. Here's how you might extend accessors.pm or work on setters/getters pragmas for Class::Tangram: use accessors::tangram( int= [ qw(foo bar) ], string = [ qw(baz quux) ] ); use setters::typed( int= [ qw(foo bar) ], string = [ qw(baz quux) ] ); use getters::noget qw(foo bar baz quux); Food for thought... -Steve
Re: [OT] accessors pragma
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 normal polymorphic fashion. I can see how 'given' would be useful, but what if I wanted to say this: $grunt.name( Patton ) .rank( General ) .add_medal( Purple heart ); Then you'd write the class that way, with explicit Cname, Crank, and Cadd_medal methods. And have you considered a twisted lvalue form like: $grunt.name = Patton .rank = General .medals += (Purple heart); We certainly considered it. Which is why we went with Cgiven instead. ;-) Damian
[OT] accessors pragma
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_value ) -bar( $another_value ); Question is: what style should be the default? I'm not looking for a debate here, just some numbers. If you don't wanna post to the list, reply to me directly. The other will likely end up as a sub-class: use accessors::classic qw( foo bar baz ); use accessors::chained qw( foo bar baz ); or perhaps: use accessors qw( foo bar baz :classic ); use accessors qw( foo bar baz :chained ); If you have a preference here, let me know. PS: Apologies for the complete lack of non-perl content up there. How's this: I just read in Wired that Buffy was not 'tired' but 'expired'? Kinda sad they had to add that third column... I remember when the wired/tired thing was actually funny. -Steve [1] yes, yet another accessor generator. difference is interface, and minimal feature creep.
Re: [OT] accessors pragma
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 ); # chaining: $obj-foo( $a_value ) -bar( $another_value ); 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 ); Having said that, I like chaining. -- .tom
Re: [OT] accessors pragma
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: # classic: print I set foo! if $obj-foo( $a_value ); # chaining: $obj-foo( $a_value ) -bar( $another_value ); 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 ); This is the 'classic' style I had in mind. Having said that, I like chaining. Duly noted. Ta for that, -Steve
Re: [OT] accessors pragma
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-foo( $a_value ); # chaining: $obj-foo( $a_value ) -bar( $another_value ); 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 object itself a valid return value until I saw Perl people doing it. I still don't.] Question is: what style should be the default? I'm not looking for a debate here, just some numbers. If you don't wanna post to the list, reply to me directly. I tend to use a simple true/false, except in complex cases where I return undef or an error message. There's no point putting any effort into giving the programmer something he already has. All of the other options fall into this category [object, new value, previous value]. S. -- Shevekhttp://www.anarres.org/ I am the Borg. http://www.gothnicity.org/
Re: [OT] accessors pragma
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-reason(ERR_BAD_PARAM)-details('foo')
unless($params{foo} $params{foo}-isa('Foo'));
--
Grand Inquisitor David Cantrell | http://www.cantrell.org.uk/david
Considering the number of wheels Microsoft has found reason
to invent, one never ceases to be baffled by the minuscule
number whose shape even vaguely resembles a circle.
-- anon, on Usenet
Re: [OT] accessors pragma
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 object itself a valid return value until I saw Perl people doing it. I still don't.] Bah. I've seen Java code doing it. I've seen EcmaScript code doing it. SmallTalk does it pretty much all the time. Besides, I like it :) -- Robin Berjon [EMAIL PROTECTED] Research Scientist, Expway http://expway.com/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: [OT] accessors pragma
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_to_string(); -- Lord Protector David Cantrell | http://www.cantrell.org.uk/david I often think that if we Brits had any gratitude in our hearts, we would put up a statue to Heinz Guderian - who probably saved us from ruin by booting our Army off the continent before we could do ourselves real harm. -- Mike Stone, in soc.history.what-if
Re: [OT] accessors pragma
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: # classic: print I set foo! if $obj-foo( $a_value ); # chaining: $obj-foo( $a_value ) -bar( $another_value ); 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. AFAIK, it was stolen from Smalltalk... Possible return values for write-accessors: true/false undef/error message the previous value the new value [I would never have considered the object itself a valid return value until I saw Perl people doing it. I still don't.] Question is: what style should be the default? I'm not looking for a debate here, just some numbers. If you don't wanna post to the list, reply to me directly. I tend to use a simple true/false, except in complex cases where I return undef or an error message. There's no point putting any effort into giving the programmer something he already has. All of the other options fall into this category [object, new value, previous value]. I see your point, but I also think it's very much up to the individual.. which is why I tread carefully to avoid a style war ;) Thanks for the feedback, -Steve
Re: [OT] accessors pragma
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 itself just because you passed a parameter. Of course you can argue that it shouldn't magically switch from getting to setting based on there being a parameter or not, but that doesn't bother me so much. They are both operations on the foo of the object and the method name doesn't make any implication about what kind of operation. The only implication is that you'll get the foo returned back when called. 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 case, the action is explicit in the method name. # this is when chaining is good, IMHO $obj-set_foo(10)-set_bar(20)-set_baz(30); Question is: what style should be the default? I'm not looking for a debate here, Ooops, sorry. If you just want numbers, then I'm for classic. I like chainability, but only if the accessor is prefixed with 'set_' or something similar. The foo() should always return the foo(), IMHO. If it doesn't then chainability is broken for accessing items. # why chaining is bad, IMHO $book-author()-name(); # author.name $book-author($a)-name(); # book.name One returns the author name, the other returns the book name. And what if $a is undef? Does that return the book name or author name? Oops, sorry. No debate. I forgot. If you have a preference here, let me know. Dark chocolate and raspberry wheat ale. :-) A
Re: [OT] accessors pragma
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 Java. poing = foo.convert_to_bar().do_stuff_to_object().convert_to_string(); I don't think chaining per se is under discussion, rather accessors that chain. Are any of those methods in your example accessors? Paul what Andy said M. -- Paul Makepeace ... http://paulm.com/ If the moon is a balloon, then it would be ruined for everyone. -- http://paulm.com/toys/surrealism/
Re: [OT] accessors pragma
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.
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 method chaining
when equivalent to foo.a(); foo.b(); is unpleasant and unnecessary.
David Cantrell attempted to pronounce:
return 0-reason(ERR_BAD_PARAM)-details('foo')
Case in point. This is an ugly neo-perlism. I like the freedom of Perl,
but this kind of thing does it no favours. It increases effort for the
maintainer, but makes no immediate saving whatsoever. It's syntax for the
purpose of syntax. It's in violation of the KISS rule.
I tell my students that one of the important things when writing code is
to write the code that your maintainer expects to see unless you have a
very good reason for doing otherwise. This reduces maintenance costs.
S.
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: [OT] accessors pragma
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::Properties
(thanks
Marcel!) and do stuff like ...
return 0-reason(ERR_BAD_PARAM)-details('foo')
unless($params{foo} $params{foo}-isa('Foo'));
Yikes!
*steve hides*
Sounds like a bit of XS magic going on there...
-Steve
Re: [OT] accessors pragma
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 ... http://paulm.com/
If the sun quacks, then grab your coathanger!
-- http://paulm.com/toys/surrealism/
Re: [OT] accessors pragma
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 likely going to kill me than not.
Actually, I note that you're also allowed to call methods on null in Java:
public class Test {
public static void main(String[] args) {
((Test)null).new InnerClass();
}
private class InnerClass {
private InnerClass() {
System.out.println(Foobar);
}
}
}
I would credit who wrote this, but I'm not sure if he'd want it known.
*snigger*
S.
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: [OT] accessors pragma
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 object. It shouldn't magically switch to returning the object itself just because you passed a parameter. Of course you can argue that it shouldn't magically switch from getting to setting based on there being a parameter or not, but that doesn't bother me so much. They are both operations on the foo of the object and the method name doesn't make any implication about what kind of operation. The only implication is that you'll get the foo returned back when called. 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 case, the action is explicit in the method name. # this is when chaining is good, IMHO $obj-set_foo(10)-set_bar(20)-set_baz(30); Question is: what style should be the default? I'm not looking for a debate here, Ooops, sorry. If you just want numbers, then I'm for classic. I like chainability, but only if the accessor is prefixed with 'set_' or something similar. The foo() should always return the foo(), IMHO. If it doesn't then chainability is broken for accessing items. # why chaining is bad, IMHO $book-author()-name(); # author.name $book-author($a)-name(); # book.name One returns the author name, the other returns the book name. And what if $a is undef? Does that return the book name or author name? Oops, sorry. No debate. I forgot. ;-) I see your point, but like I've said before, methinks this is a style issue. I'm trying to find out which style most people prefer so the majority of people can benefit from the module. But you bring up some points I've gotta answer -- first off, 'set_' 'get_' don't seem to be too popular (laziness?) so unless people prove me wrong here, they're out for accessors.pm. [1] 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 If you pass an empty list, it will act as a get and your original code would prolly break: $book-author(@a)-name; # buggy code if @a = ()! If you have a preference here, let me know. Dark chocolate and raspberry wheat ale. :-) Mmm.. evil tempter.. Uppercanada used to do this maple beer that was really nice... digs around try: http://www.uppercanada.com/template.asp?CName=ATheBeer2 -Steve [1] As a complete aside, I don't think 'get_' and 'set_' are bad ideas. There's no reason reason someone couldn't write 'accessors::setget', or 'getters' and 'setters' pragmas. Michael Schwern recently pointed me to Ruby's 'attr_reader' and 'attr_writer' shortcuts - see http://www.rubycentral.com/book/tut_classes.html
Re: [OT] accessors pragma
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 method chaining
when equivalent to foo.a(); foo.b(); is unpleasant and unnecessary.
I saw what you meant after I'd posted. I still disagree with you.
return 0-reason(ERR_BAD_PARAM)-details('foo')
Case in point. This is an ugly neo-perlism. I like the freedom of Perl,
but this kind of thing does it no favours. It increases effort for the
maintainer, but makes no immediate saving whatsoever. It's syntax for the
purpose of syntax. It's in violation of the KISS rule.
Ugliness is in the eye of the beholder.
When I'm programming in perl, I will program using a perlish idiom.
When programming in $other_language I will try to use the
other_languageish idiom.
I simply have to disagree that it increases effort for the maintainer.
Sure, to understand that line, you have to understand that I'm using
Scalar::Properties. But then, you have to understand what
Scalar::Properties does if you're going to understand the whole thing,
not just to understand that one line. My documentation makes it very
clear that I'm using that.
I tell my students that one of the important things when writing code is
to write the code that your maintainer expects to see unless you have a
very good reason for doing otherwise. This reduces maintenance costs.
You won't get any argument from me there. I see nothing particularly
unexpected about what I'm doing, nothing which the maintainer couldn't
be expected to understand after reading the documentation.
--
David Cantrell | Reality Engineer, Ministry of Information
If you have received this email in error, please add some nutmeg
and egg whites, whisk, and place in a warm oven for 40 minutes.
Re: [OT] accessors pragma
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 which makes perfect sense when read in conjunction with the
documentation. What, exactly, do you find difficult about it?
--
David Cantrell | Reality Engineer, Ministry of Information
It would be reasonable to judge cannabis less of a threat to health
than alcohol or tobacco ... this should be borne in mind by social
legislators who, disapproving of other people's indulgences, seek
to make them illegal.
-- The Lancet, Volume 352, Number 9140, 14 November 1998
Re: [OT] accessors pragma
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, 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 you find difficult about it?
The very fact that one has to resort to the documentation to discover that
this is just an assbackwards way of doing something perfectly simple. That
in itself quite clearly increases effort for the maintainer, in
contradiction of your earlier mail.
S.
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: [OT] accessors pragma
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 you find difficult about it? The very fact that one has to resort to the documentation to discover that this is just an assbackwards way of doing something perfectly simple. That in itself quite clearly increases effort for the maintainer, in contradiction of your earlier mail. As I already explained, I am using a particular module for reasons which I have documented. I assume that the maintainer has RTFM. I assume that they have read the documentation of any dependencies with which they are not familiar. Where the dependencies are unusual (as in this case) I have made a point of highlighting them in the docs. Therefore they will understand what is happening there. They will understand both what that line does, and why I wrote it. Or do you believe that documentation exists for the sake of documentation and for no useful purpose? -- David Cantrell | Reality Engineer, Ministry of Information Do not be afraid of cooking, as your ingredients will know and misbehave -- Fergus Henderson
Re: [OT] accessors pragma
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
Re: [OT] accessors pragma
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 public;
submethod BUILD ($id) { $.serial = $id }
method title () { return $.rank $.name }
}
my $grunt = DogTag.new(71625371);
$grunt.name = Pyle;
$grunt.rank = Private;
print $grunt.title ($grunt.serial)\n;
And Perl 6 supports chaining of accessors using $_ and the unary dot
operator, not return values:
given $grunt {
.name = Patton;
.rank = General;
push .medals, Purple heart;
}
The closest equivalent Perl 5 would be:
package DogTag;
sub new {
my ($class, $id) = @_;
bless { name=undef, rank=undef, serial=$id, medals=[] },
$class;
}
sub name : lvalue { $_[0]{name} }
sub rank : lvalue { $_[0]{rank} }
sub serial{ $_[0]{serial} }
sub medals{ $_[0]{medals} }
sub title { return $_[0]{rank} $_[0]{name} }
package main;
my $grunt = DogTag-new(71625371);
$grunt-name = Pyle;
$grunt-rank = Private;
print $grunt-title, (, $grunt-serial, )\n;
And for chaining:
for ($grunt) {
$_-name = Patton;
$_-rank = General;
push @{$_-medals}, Purple heart;
}
Damian
Re: [OT] accessors pragma
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 is odd. I thought classic returned $new_foo, not $old_foo. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
