Warp wrote:
>   In an OO language where constructing an object also initializes it (so that
> it's impossible to have uninitialized objects, which makes sense), it may be
> rational to have more than one constructor for constructing objects in
> different ways. It may also be rational to have a default-constructed object,
> with some sensible default values. (And in some cases being able to
> default-construct objects might be a prerequisite.)

Agreed. This is the main situation where I find it's actually a PITA to 
follow the rule. :-) But usually for this sort of thing, your constructor 
doesn't take a whole lot of arguments, so making any of them default values 
would be reasonable.

I'd expect the best answer would be to have the default constructor (if it 
exists) not take any arguments and use a different name for constructors 
that take arguments. Calling Point.initialize(0,0) would be just like 
calling Point.new().

Of course, using default arguments assumes that there *is* a valid default. 
Unless your language supports telling you which arguments didn't get passed 
from the caller, you sometimes *have* to use the separate-call pattern.

>     Point(); // Default constructor, initializes to (0,0)
>     Point(int x, int y); // Initializes to the given values

The same guy also thinks overloaded function names are a bad idea, too, 
altho his reasoning on that seems less obvious.  (Other than when you 
inherit, you wind up with problems if you want to override one version and 
not the other, I guess.)

>   It becomes cumbersome when you need only a temporary, for example like:

I don't think the original proponent (Meyers) was too worried about 
cumbersome as much as he was about correctness and reusability. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message