Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

simple OO constructor

by galacticdruid (Initiate)
on Sep 23, 2001 at 01:28 UTC ( #114095=snippet: print w/replies, xml ) Need Help??
Description: This is the object constructor used in perltoot. I put it in my editor so I don't have to retype it all the time.
sub new {
  my $proto = shift;
  my $class = ref($proto) || $proto;
  my $self  = {};
  bless ($self, $class);
  return $self;
Replies are listed 'Best First'.
Re: simple OO constructor
by merlyn (Sage) on Sep 23, 2001 at 03:02 UTC
    There is also a school of thought (in which I'm enrolled {grin}) that an object should also be a "valid" object upon instantiation, and that a caller should never be given a partially constructed object that has to be prodded a bit before it would be valid for the rest of the program.

    Since the point of an object is to hold varying internal state, creating an object with "new" that has no internal state almost certainly means that the object is not yet "initialized" and thus does not yet represent a valid object. (I can think of a few rare exceptions, but those are exactly that, rare.)

    So, this "simple constructor" is nothing more than an interesting sequence of code, but in practical use, practically worthless.

    In perlboot, I even argue that constructors shouldn't simply be called "new", since almost any real constructor will require some sort of state that cannot be determined without the use of parameters, and naming the method to match the intent of the parameters makes it somewhat clearer. As a practical famous example, note the constructor for DBI is called connect and not new. There's no way to create a "new DBI object". Only a connected one, one that has purpose and internal state and can be used with other calls. This is a very good model to follow.

    -- Randal L. Schwartz, Perl hacker

      There is also a school of thought (in which I'm enrolled {grin}) that an object should also be a "valid" object upon instantiation, and that a caller should never be given a partially constructed object that has to be prodded a bit before it would be valid for the rest of the program.

      Indeed. I've learned the hard way that approaches to OO that leave objects in an "I'm almost valid, really!" state are either asking for trouble now, or are investing in future trouble for the poor soul who picks up the code a year later, tries to extend it, and doesn't get the partial initialization exactly right.

      Clients of an API should never--at least never in production code--be handed invalid objects with the expectation that the client will do the right thing to get the object into a valid state.

      At the very least, this means that initialization parameters passed to new need to be honored.

        sub new {
            my $proto = shift;
            bless { @_ }, ref($proto) || $proto;
      This suffices to create instances of some simple objects, but often times setup is a bit more complicated. One pattern from the Smalltalk world is to separate initialization from instantiation, using a generic method for the latter, and a method for the former that subclasses can override.

      Using the pattern, the base class implements new (instantiation) and initialize (initialization).

      sub new { my $proto = shift; my $self = bless { @_ }, ref($proto) || $proto; $self->initialize(); } sub initialize { my $self = shift; ... initialization for the base class ... }
      Subclasses then specialize the initialization.
      sub initialize { my $self = shift; # First initialize our inherited aspects $self->SUPER::initialize(); ... initialization specific to the subclass ... }
      When I then create an instance of a subclass in this hierarchy, I get the generic new, followed by a pre-order invocation of initialize. I.e., first the object is initialized as if it is a member of the base class, and the initializations for subclasses happen in the order of refinement until I get down to the class I targeted. I end up with a fully initialized object.

      Using this scheme, at least with the class of objects for which this type of initialization works, I'm guaranteed to get a valid object back from new.

      What are your views on not returning a valid object, but fixing it transperrantly when needed? Object::Realize::Later is what I mean.
      zz zZ Z Z #!perl
Re: simple OO constructor
by japhy (Canon) on Sep 23, 2001 at 01:43 UTC
    Some people think $obj->new is "wrong". Regardless, I'd shrink the constructor to:
    sub new { bless {}, ref($_[0]) || $_[0]; }

    Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
    s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: snippet [id://114095]
[LanX]: First day after holidays ... and already stressed by the fact that colleagues changed stuff without communication ... apparently I'm the only one trying to fight entropy
[Corion]: LanX: The command is always in the history if you typed it in before. If you didn't type the command into the command line, it will not be there. I think there is doskey which can stuff command lines into the history
LanX damns the cult of CB ;-)
[LanX]: please forget my last 3 posts
[LanX]: Yeah option a doesn't go into history
[LanX]: probably I need to teach the app to restart after C-c Kill
[Corion]: LanX: Maybe have an infinite-loop cmd file? Much easier than trying to manage that from within Perl IMO
[Corion]: Alternatively, relaunch the application from cron (or a Windows cron) every minute
[LanX]: will try infinite loop ...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (12)
As of 2017-03-27 15:50 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (320 votes). Check out past polls.