Re: Yet another OO question

2006-06-10 Thread Lawrence Statton

Shawn wrote:
I would prefer it to return the old value:
   
sub foo {
  my $self = shift;
  my $old_foo = $self-{'foo'};
  $self-{'foo'} = shift if @_  0;
  return $old_foo;
}
   
   

Someone asked:  (Sorry, I've lost the attribution)

   
   If you set a new value, why would you want your client to still be
   using the old value?
  

I (Lawrence) responded:

  Because you may need to put the old value back.  It's more of a
  philosophical question.  What should the mutator return? 
  
  The Object Purist says, Nothing -- it should be declared void.
  
  Another school says, It should return the value you just set it to.
  I think is useless -- it's a tautology.  You KNOW what value you just
  set it to.
 

Jenda wrote:

 You know the value you assigned to a variable as well so why does 
   $x = 5
 evaluate to 5 and not the old value of $x? Maybe because you may want 
 to write
 
   $x = $y = $z = 0;

You may be amazed the number of beginning programmers who are baffled
by that construct.  

 
 I bet most people would be very surprised if they ended up with $x 
 containing the old value of $y, $y with the old value of $z and $z 
 equal to 0. So IMHO just like
   $x = 5
 evaluates to 5 and
   $h{key} = 5
   $h[$i] = 5
   $hr-{key} = 5
 all evalate to 5 so should
   $obj-size(5)
 evaluate to 5.

A very good argument.

 
 I'm not sure it's such a bad habit. Though probably it's better to 
 use something like this:
 
   for ($fruit) {
   $_-name('apple');
   $_-color('red');
   $_-texture('crunchy')
   }


Hrm ... a Clever Construction, indeed.  Our local style guide bans the
use of for without an explicit index variable , so that bit of
cleverness would lead to the following silly code:

for my $localfruit ($fruit) { 
  $localfruit-name('apple');
  $localfruit-color('red');
  $localfruit-texture('crunchy');
}

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
Lawrence Statton - [EMAIL PROTECTED] s/aba/c/g
Computer  software  consists of  only  two  components: ones  and
zeros, in roughly equal proportions.   All that is required is to
sort them into the correct order.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Yet another OO question

2006-06-10 Thread Paul Johnson
On Fri, Jun 09, 2006 at 09:18:22AM -0700, Lawrence Statton wrote:

 Our local style guide bans the
 use of for without an explicit index variable

Every style guide should have a rule that says break these rules if you
consider it sensible to do so, but be prepared to justify your
decision, or something to that effect.  Especially so if the rules are
draconian.  Otherwise you'll end up with stuff like

# Remove the first space from all thingies

use Readonly;
use Regexp::Autoflags;

Readonly my $SPACE = q{ };  # Single space
Readonly my $EMPTY_STR = q{};   # Empty string

foreach my $thingy (@thingies) {
$thingy =~ s{ $SPACE }
{ $EMPTY_STR }o;
}

instead of

s/ // for @thingies;

or something.

Astute readers may recognise the rules I am attempting to use.
(Incorrectly, in all probability.)  But I am really trying to make a
general point rather than pick holes in any particular set of rules.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Yet another OO question

2006-06-10 Thread JupiterHost.Net



Paul Johnson wrote:


Astute readers may recognise the rules I am attempting to use.


Damian Conway's Perl best Practices, *everyone* should own this book :)

Mr. Johnson just got a few more points in my book ;p

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Yet another OO question

2006-06-08 Thread Graeme McLaren
Hi all, I've just been reading a bit about accessor get/set methods.  I have 
a method:


sub even{
   my $self = shift;
   my $even   = shift;

   $self-{_even} = $even if defined($even);
   return $self-{_even};
}


This basically does what a get and set method would do.  So why would I need 
a set/get methods?  This value is passed to the object like so:


$object-even('even_value');


This is setting the value here, although I'm sure this isn't the recommended 
way of doing it.  Should objects only have values set when instatiating?


my $object = the_object-new('even_value');


Basically I think I need to clarifiy the difference between an accessor / 
mutator type method and get/set methods, can anyone explain this?



Cheers,

G :)



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Yet another OO question

2006-06-08 Thread Ricardo SIGNES
* Graeme McLaren [EMAIL PROTECTED] [2006-06-08T05:44:05]
 Hi all, I've just been reading a bit about accessor get/set methods.  I 
 have a method:
 
 sub even{
my $self = shift;
my $even   = shift;
 
$self-{_even} = $even if defined($even);
return $self-{_even};
 }
 
 
 This basically does what a get and set method would do.  So why would I 
 need a set/get methods?  This value is passed to the object like so:

It's a question of style, largely.  Some people prefer their code to be
very clear about whether your getting or setting.  Using explicit set and get
methods can also help prevent bugs; you won't accidentally make a read-only
value writeable, because you will avoid writing a set_ro_value method -- if you
only have a get-and-set ro_value method, you might forget to special-case it to
be get-only.

Also, you'd probably avoid bugs like the one you introduced above.  What
happens if I want to clear the even value?

  $obj-even(undef);

This does not affect the value; I can't undef even.

You probably wanted:

  sub even {
my $self = shift;

return $self-{even} unless @_;
return $self-{even} = shift @_;
  }

-- 
rjbs


signature.asc
Description: Digital signature


Re: Yet another OO question

2006-06-08 Thread Anthony Ettinger

On 6/8/06, Ricardo SIGNES [EMAIL PROTECTED] wrote:

* Graeme McLaren [EMAIL PROTECTED] [2006-06-08T05:44:05]
 Hi all, I've just been reading a bit about accessor get/set methods.  I
 have a method:

 sub even{
my $self = shift;
my $even   = shift;

$self-{_even} = $even if defined($even);
return $self-{_even};
 }


 This basically does what a get and set method would do.  So why would I
 need a set/get methods?  This value is passed to the object like so:

It's a question of style, largely.  Some people prefer their code to be
very clear about whether your getting or setting.  Using explicit set and get
methods can also help prevent bugs; you won't accidentally make a read-only
value writeable, because you will avoid writing a set_ro_value method -- if you
only have a get-and-set ro_value method, you might forget to special-case it to
be get-only.

Also, you'd probably avoid bugs like the one you introduced above.  What
happens if I want to clear the even value?

  $obj-even(undef);

This does not affect the value; I can't undef even.

You probably wanted:

  sub even {
my $self = shift;

return $self-{even} unless @_;
return $self-{even} = shift @_;
  }

--
rjbs


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEiBrL5IEwYcR13KMRAnUiAJ9jORCdmqcxxvJSLnzfg2B0BXJdMACZAU3v
H8WkVST4w7lrACbWr2hdtLY=
=7rTT
-END PGP SIGNATURE-





i prefer the return once method:

sub foo
{
   my $self = shift;
   if (@_ == 1) { $self-{'foo'} = shift; }

   return $self-{'foo'};
}

--
Anthony Ettinger
Signature: http://chovy.dyndns.org/hcard.html

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Yet another OO question

2006-06-08 Thread Mr. Shawn H. Corey
On Thu, 2006-08-06 at 10:56 -0700, Anthony Ettinger wrote:
 i prefer the return once method:
 
 sub foo
 {
 my $self = shift;
 if (@_ == 1) { $self-{'foo'} = shift; }
 
 return $self-{'foo'};
 }

I would prefer it to return the old value:

sub foo {
  my $self = shift;
  my $old_foo = $self-{'foo'};
  $self-{'foo'} = shift if @_  0;
  return $old_foo;
}


-- 
__END__

Just my 0.0002 million dollars worth,
   --- Shawn

For the things we have to learn before we can do them, we learn by doing them.
  Aristotle

* Perl tutorials at http://perlmonks.org/?node=Tutorials
* A searchable perldoc is at http://perldoc.perl.org/



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Yet another OO question

2006-06-08 Thread Anthony Ettinger

On 6/8/06, Mr. Shawn H. Corey [EMAIL PROTECTED] wrote:

On Thu, 2006-08-06 at 10:56 -0700, Anthony Ettinger wrote:
 i prefer the return once method:

 sub foo
 {
 my $self = shift;
 if (@_ == 1) { $self-{'foo'} = shift; }

 return $self-{'foo'};
 }

I would prefer it to return the old value:

sub foo {
  my $self = shift;
  my $old_foo = $self-{'foo'};
  $self-{'foo'} = shift if @_  0;
  return $old_foo;
}


--
__END__

Just my 0.0002 million dollars worth,
   --- Shawn



If you set a new value, why would you want your client to still be
using the old value?



--
Anthony Ettinger
Signature: http://chovy.dyndns.org/hcard.html

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Yet another OO question

2006-06-08 Thread Lawrence Statton
  I would prefer it to return the old value:
 
  sub foo {
my $self = shift;
my $old_foo = $self-{'foo'};
$self-{'foo'} = shift if @_  0;
return $old_foo;
  }
 
 
 
 If you set a new value, why would you want your client to still be
 using the old value?

Because you may need to put the old value back.  It's more of a
philosophical question.  What should the mutator return? 

The Object Purist says, Nothing -- it should be declared void.

Another school says, It should return the value you just set it to.
I think is useless -- it's a tautology.  You KNOW what value you just
set it to.

Yet another thought is The previous value -- that is at least
something you didn't know going INTO the call - so it does increase
the total knowledge of your program.

My hitherto prefered answer is It should return the object.  Only
because I (used to) like to chain method calls.  I've since lost this
bad habit.

$fruit-name('apple')-color('red')-texture('crunchy');

So, I am now wavering between the 'previous value' and 'nothing'
options.  

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
Lawrence Statton - [EMAIL PROTECTED] s/aba/c/g
Computer  software  consists of  only  two  components: ones  and
zeros, in roughly equal proportions.   All that is required is to
sort them into the correct order.



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Yet another OO question

2006-06-08 Thread Anthony Ettinger

On 6/8/06, Lawrence Statton [EMAIL PROTECTED] wrote:

  I would prefer it to return the old value:
 
  sub foo {


I see...I i've been more or less looking at the current state

$curr = $foo-bar();
$old = $curr;

$curr = $foo-bar('new value');



--
Anthony Ettinger
Signature: http://chovy.dyndns.org/hcard.html

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response