OT: copy constructor

in reply to Re: scope and declaration in local packages
in thread scope and declaration in local packages

++ to your explanation. Brings to mind a post of mine from long ago where someone alerted me to the different program execution phases that variable declaration and variable assignment happen in. It was new to me then.

I am curious about your comment regarding the "copy constructor technique" - I assume you mean a constructor snippet like:

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

I am curious because I vaguely recall some prior nodes deriding this practice, mostly as I recall claiming that it's cargo-cult coding and the person writing the code doesn't understand what it does. But what makes you say that this usage is almost always an error? As long as you understand what it does, it seems like an acceptable shortcut to object instantiation, although I personally wouldn't use it. Is there some hidden danger here that I don't know about? If I remember correctly, my (outdated) edition of The Camel uses code like this.

Comment on OT: copy constructor Select or Download Code

Replies are listed 'Best First'.
Re: OT: copy constructor by chromatic (Archbishop) on Jan 30, 2011 at 16:33 UTC
But what makes you say that this usage is almost always an error? In the original code, `$class` went entirely unused. All of the shenanigans to figure out whether the invocant is a reference are useless. The design problem with this technique is that it allows you to write: `my $object = Class->new(); my $otherobj = $object->new();` [download] What relationship should `$otherobj` have with `$object`? Does it have any? It's easy to expect a prototypal relationship between the two, or one where the former's instance data somehow sets the latter's, but there's almost never any code in the copy-and-paste copy constructor to set this. Why create an interface that does nothing? Worst yet, consider what happens if someone invokes the constructor like this: o `my $object = Class::new( {} );` I know that's unlikely, but the copy constructor technique will silently create an object blessed into a package called `HASH`. Without the copy constructor technique, Perl will happily throw an exception about attempting to bless into a reference. This technique silences useful error messages for no good reason. As far as I can tell, the only reason this code persists is because someone put it in the documentation as an example of a cool technique, and people started thinking it was necessary because the documentation explained Perl 5 objects as crazy black boxes that require a lot of arcana.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: OT: copy constructor
by chromatic (Archbishop) on Jan 30, 2011 at 16:33 UTC

But what makes you say that this usage is almost always an error?

In the original code, $class went entirely unused. All of the shenanigans to figure out whether the invocant is a reference are useless.

The design problem with this technique is that it allows you to write:

my $object   = Class->new();
my $otherobj = $object->new();
[download]

What relationship should $otherobj have with $object? Does it have any? It's easy to expect a prototypal relationship between the two, or one where the former's instance data somehow sets the latter's, but there's almost never any code in the copy-and-paste copy constructor to set this.

Why create an interface that does nothing?

Worst yet, consider what happens if someone invokes the constructor like this:

my $object = Class::new( {} );

I know that's unlikely, but the copy constructor technique will silently create an object blessed into a package called HASH. Without the copy constructor technique, Perl will happily throw an exception about attempting to bless into a reference. This technique silences useful error messages for no good reason.

As far as I can tell, the only reason this code persists is because someone put it in the documentation as an example of a cool technique, and people started thinking it was necessary because the documentation explained Perl 5 objects as crazy black boxes that require a lot of arcana.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom