I mean, you wouldn't want an uninitialised instance of your class floating around in the wild would you?

I aim for avoiding initialization most of the time. :) I/O heavy initialization for database backed objects is best saved until absolutely needed, and possibly saved until more than one object can be initialized at the same time. How many objects get constructed and never used? Make construction cheap and it doesn't matter. Save the memory and disk and CPU for the stuff you really need to use.

I have a rule now for my code...save all work until it's proven to be necessary. Don't initialize an object until a method is called on that object that requires it to be initialized. Extending that, use require-on-demand instead of 'use'. Don't even compile dependency modules until a caller wants an object of their type constructed. autouse packages when trying to get legacy code to perform (just refactor out those pesky imports and that indirect object syntax ... your maintainers don't really want either of those anyway). Use Abstract Factory with a require-on-demand design for new code. Design for modular run-time, not just modular maintain-time.

As long as objects can identify themselves uniquely and know whether they've been initialized or not, then the rest is no big deal. No need for fully initialized objects at all times.

Hm. I cannot see the point in instantiating an object that will never be used. Better to leave the variable as undef until it is needed and then initialise it.

To my way of thinking, instantiating uninitialised objects is as short sighted as declaring variables in C without initialising them.

And auto-initialising on demand sounds even worse. Maybe I'd just need to see a real-world example of use to convince me otherwise, but I am sceptical.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I share your scepticism BrowerUk, I have to put up with this way of working every day on the current contract - where the majority of perl 'developers' come from a Java background and this (the separation of creation and initialisation) is not atypical of their Java orientated modus operandii - something that they're seemingly incapable of veering away from.

Update:

Hmmm, having said that, I notice that Damian Conway (TheDamian ?) posits such an approach as the basis for the constructor inheritance problem.

A user level that continues to overstate my experience :-))

Hmm, well maybe I'm just in violent agreement with the "partial initialization" camp here. I'm just more partial to less initialization. :)

I use a simple constructor, inherited by every package. It accepts random name-value pairs as arguments, stores them internally, and returns a blessed object. Nothing more. Usually "id" and reftype are all my objects need up front. I don't use anything like a UNIVERSAL::new(), because that implies too many assumptions about third party code operating in my ecosystem. My constructor does get inherited by all of my classes though, to deliver a consistent construction behavior and common method call syntax throughout my frameworks.

I don't presume in my constructor to know how the objects will be used in their lifetime. The only valid assumption in my use model is that construction has been requested. When a method gets called that requires initialization, then apparently a use model requiring initialization is being used, so initialization gets done then.

I've worked with abstracting SCM systems quite a bit like ClearCase and Perforce. In many cases, an object representing a file or version may not need to be initialized with the attributes from the database in order to be able to request the SCM system do something interesting or useful with that file. Self-identification is sufficient. Other custom integration operations in user space will want more inforamtion from the database in order to complete their task, and will trigger initialization.

One issue I used to have with having a half/half approach was inconsistency in maintenance. When developers saw initialization happening in the constructor, it was easy to just dump more stuff in there, slowing everything down. When there is "no" constructor available for initialization, and every method becomes responsible for whatever initialization it needs to operate properly, it's easier to maintain a consistent level of performance imo. Never doing more work than required at any point during execution.

It's absolutely preferable not to even construct objects that won't be used, but its hard to call methods on things that don't exist. Sufficiently abstracted frameworks cannot always make assumptions about use models.

--Dave