Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^3: Perl Object Initilization

by BrowserUk (Pope)
on Jun 10, 2011 at 07:09 UTC ( #909051=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Perl Object Initilization
in thread Perl Object Initilization

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.


Comment on Re^3: Perl Object Initilization
Re^4: Perl Object Initilization
by Bloodnok (Vicar) on Jun 10, 2011 at 10:32 UTC
    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 :-))
Re^4: Perl Object Initilization
by armstd (Friar) on Jun 10, 2011 at 17:36 UTC

    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

      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.

      Neither of those "benefits" comes as a result of your "simple, inherited constructor". You get them for free regardless. I think any further expression of my scepticism is redundant.

      It's OO Jim, but not as we know it :)


      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.
        Neither of those "benefits" comes as a result of your "simple, inherited constructor". You get them for free regardless. I think any further expression of my scepticism is redundant.

        Well no, you don't get name/value pair argument handling for free. No, you don't get consistent internal object structure for free.

        Really have no idea what you're talking about getting for free. Perl is work, man. Only thing that makes a difference is designing where the work gets done.

        --Dave

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://909051]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (6)
As of 2014-10-24 23:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (138 votes), past polls