Re: Re: OOP,

[hding]

If you have a variety of different constructors, though, it would seem to be possible that two of them might need to specify the same default value for a variable (and it might be impossible to rig things up so that one could get it by invoking the other at some point), so something like this would help keep things in sync if a change ever needed to be made.

[ichimunki]

"a variety of different constructors"? I may be a newcomer to OOP, but that's a recipe for disaster unless you factor out the commonalities at the package level and create private methods that do those parts for your various public constructors.

Another solution, if you absolutely insist on a myriad of monolithic constructor routines (again, these sound like a maintenance nightmare), is to create a package global that holds a default $self to be assigned when you declare my $self the first time in each constructor, and then over-ridden as the parameters are dealt with.

[dragonchild]

Think about it this way:
1. You don't know anything about the internals of the object.
2. You have been told that the object will take either:
   • a list of values (in a certain order and restrictions on the values)
   • a hash (with a certain set of keys and restrictions on the values)
   • another object like itself
   • another object similar to itself (maybe a parent class?)
In order to allow for the four completely different ways to construct the object, the object has to have four different constructors. In C++, these would four separate functions with different munged names. In Perl, we'd have one function that may (or may not) branch out into one or more helper functions. The copy constructor, for example, might call the clone() function on the object passed in. (clone() would be used in a similar fashion.)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[ichimunki]

Well that's just it. Having to know which constructor to call based on my type of inputs is somewhat unnecessary (in Perl), as the constructor itself has many ways to determine what it was given to work with. But I see your point, especially since I would gladly prefer a Class::copy->( $existing_instance ) method over simply doing $existing_instance->new(), unless the whole idea was to create a default or blank instance and not a copy of the existing instance.

But as to how those are implemented inside the class-- if you aren't factoring out any commonalities in your constructors into private methods you are duplicating code somewhere along the line. Hence, even your four different examples should be little more than wrappers around a private _new method. To me that's the important point here.

note: and either way, none of this precludes using package-scoped variables to define default attributes as a way of supporting defaults even in highly compartmentalized constructors.