Mailing List Archive

Re: Type dispatch in object creation
[.courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc,
dov@menora.weizmann.ac.il (Dov Grobgeld) writes:
:I have started to write an image manipulation library for Perl and I
:decided to try to make it object oriented. This is my first real
:effort to write object oriented perl and I have some questions about
:conventions.
:
:I feel that I have the need to create several constructors with inputs
:of different type. E.g.
:
: $img1 = Image::new($filename); # The image is read from filename
: $img2 = Image::new($img1); # Image copying
: $img3 = Image::new([$type, $width, $height, $data]); # The image
: # Is created from a list reference.
:
:This obviously means that I have to do a "type switch" in the
:beginning of the Image::new function to figure out what type of
:parameters there are. Has anybody done this in any of the Perl
:libraries?
:
:Can the second form above be handled by overloading of the assignment
:operator? Is such an overloading at all possible? It worries me that
:in:
:
: $a = Complex::new(1,1);
: $b = Complex::new(2,2);
: $c = Complex::new(3,3);
: $d = Complex::new(4,4);
: $c = $a;
: $d = $a + $b;
:
:$c becomes just a another reference to the object $a, whereas $d is
:a new independent object.

Hm... you mean lest someone should change $a and inadvertently
affect $c? Perhaps a copy constructor would be good here, but that
seems heavy handed. I'll CC the perl-porters list for advice.

One thing though; you seem making a common mistake:

$a = Module::new();

Is a simple module call. It is *NOT* a class object call. It
gets no arguments, does no inheritance, etc.

On the other hand, this is:

$a = Module->new();

This time, new() gets an implicit extra $self argument of 'Module',
and inheritance is used to locate it.

One way I've seen to avoid letting people screw this up
is like this:

package Module;
use Exporter;
@ISA = qw(Exporter Module::__private__);

package Module::__private__;

### all methods go here ###

sub new { } # make sure to use 2-arg bless


I'm not sure what downsides there are to this, but
it stops anyone from accidentally miscalling methods
as functions.
--
Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com


150 years ago everybody was a Christian Scientist. --dmr
Re: Type dispatch in object creation [ In reply to ]
Tom Christiansen writes:
> In comp.lang.perl.misc,
> dov@menora.weizmann.ac.il (Dov Grobgeld) writes:
> :Can the second form above be handled by overloading of the assignment
> :operator? Is such an overloading at all possible? It worries me that
> :in:
> :
> : $a = Complex::new(1,1);
> : $b = Complex::new(2,2);
> : $c = Complex::new(3,3);
> : $d = Complex::new(4,4);
> : $c = $a;
> : $d = $a + $b;
> :
> :$c becomes just a another reference to the object $a, whereas $d is
> :a new independent object.
>
> Hm... you mean lest someone should change $a and inadvertently
> affect $c? Perhaps a copy constructor would be good here, but that
> seems heavy handed. I'll CC the perl-porters list for advice.
>

Does not seem people did their homework here... The form
$d = $a + $b;
implies that the class is overload'ed. Overloading implies copy
constructor. See perlovl.{pod,1}, or overload.pm with newer (not yet
existing ;-) perl.

Well, copy constructor has a default value, so most probably (unless
Complex uses an opaque typemap'ed type) it will do what is needed:
$c = $a
will do a shallow copy, but a consequent $a++ will call a copy
constructor, which may do a deep copy or die, depending on
implementation of Complex.

Ilya