in reply to (jeffa) 3Re: My first stab at OO perl...
in thread My first stab at OO perl...

Although you should know that Damian uses ref($caller) extensively in his book (see all the CD::Music examples). I'm not saying that's right, but it makes the context of the recommendation to read the book sound sort of self-contradictory.

Me, I've been castigated by merlyn for using ref($caller), and I've (sort of) come around to his view. That is, $obj->new() just always struck me as a perfectly reasonable way to obtain a new, 'blank' object of the object's class. Expecting it to clone just never made any sense to me (if you meant it to clone, you'd've named it clone(), right?). But I've come to sense that I'm in the minority on this one, and calling $obj->new() hasn't ever been truly necessary in my code anyway; if this is going to be that confusing to that many people, then it's a de facto bad idea. (Though still, I'd like to know how many people would really be confused by this, and how many wouldn't be, but are just saying that someone else may get confused.)

-- Frag.

  • Comment on Re: (jeffa) 3Re: My first stab at OO perl...

Replies are listed 'Best First'.
Why ref($proto) should be avoided
by jeffa (Bishop) on Jul 17, 2002 at 06:10 UTC

    You almost got me. :)

    On page 103, TheDamian explains that calling a 'constructor' as an object method is a lazy way to copy an object, but observe what happens when you change an object's attributes at runtime and try to clone it: 
    use strict;
use Clone qw(clone);

my $foo = foo->new();
$foo->{spam} = {spam =>'eggs'};

my $bad_clone  = $foo->new();
my $good_clone = clone($foo);

$bad_clone->{spam}->{spam}  or warn "bad has no eggs";
$good_clone->{spam}->{spam} or warn "good has no eggs";

package foo;
use strict;

sub new {
   my $class = shift;
   my $proto = ref($class) || $class;
   return bless {}, $proto;
}

    [download]
    TheDamian also explains on page 105 that
    While many experts view the overloading of constructors as object copiers to be a natural extension of their functionality, others consider the technique unintuitive, too subtle, and more likely to produce obscure and hard-to-maintain code.
    and on page 106
    If you have a choice, it's probably better to code a seperate clone method. Apart from keeping your individual methods simpler and less prone to bugs, the method's name will force client code to be more clearly self-documenting.

    jeffa

    doesn't like spam
[reply]
[d/l]
      Still, that's after using ref($caller) in all the preceding examples. Ditto in the 'final version' of CD::Music (p.114). And you've got to admit, "probably better" aint much of a condemnation.

      -- Frag.

[reply]
        Well, i wouldn't say all the preceding examples. He does use some form of ref($caller) extensively throughout the book, but not in every example.

        And i can admit that "probably better" ain't much of condemnation, but not as much as i can admit that it ain't much of a recomendation either. I see nothing wrong with simpler methods that are less prone to bugs and are more clearly self-documenting. :)

        Update: i should mention that Class::MethodMaker's new_hash_init specifier makes for a very robust instance constructor. Consider using it if you don't like having to write your own clone method.

        jeffa

        L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]

In Section Seekers of Perl Wisdom