Re: What is the best way to set options in a constructor

From: Wiggins D Anconia (wiggins_at_danconia.org)
Date: 10/23/03

  • Next message: Chris McMahon: "No dice;details . RE: run in background from qx//?" 
    Date: Thu, 23 Oct 2003 10:23:14 -0600
To: beginners@perl.org

    > >>>>> "Steve" == Steve Grazzini <grazz@pobox.com> writes:
    >
    > Steve> Now, I don't particularly like "$obj->new", but it's not really
    "wrong"
    > Steve> either. If you want to let people call your constructor that
    way, then
    > Steve> go ahead and use "ref($proto) || $proto". And conversely, if
    you think
    > Steve> "$obj->new" is an abomination, then just use "my $class = shift".
    >
    > Steve> But either way, make an informed decision. Don't cargo-cult it in
    > Steve> because it's in the examples in perltoot. And don't cargo-cult
    it out
    > Steve> because Randal smacks you whenever you use "ref($proto)" in public.
    >
    > Well, if you want to obscure your code, go ahead. But I thought
    > real world code wasn't about JAPHs and Golf and Obfu-Perl.
    >
    > So, it has no place in *real world* code. That's all I'm saying. It
    > obscures more than it helps, and shouldn't be carbon-copied into every
    > constructor out of habit. If you use it, DOCUMENT THE HELL OUT OF IT,
    > because it comes out of left field.
    >
    > Note that I have no problem with other method names being used
    > for both class methods and instance methods. It's only the highly
    > overloaded term "new" that I'm referencing here.
    >
    > In fact, I can make a (albeit weaker) case that "new" is the wrong
    > name for a constructor anyway, and that constructors should be named
    > as natural verbs, like DBI's "connect". But nobody from the C++ camp
    > would ever support me on that, because their minds are already
    > corrupt. :)
    >

    I imagine it is just the cargo culting because of lack of examples like
    Randal's. Ironically I tend to fall in the "programming explicitly" camp
    where I want my code to reflect exactly what it does, but I am in the
    cargo cult group because *everything* I had read explained it that way.
    Having seen Randal's argument, knowing my own biases, I do prefer his
    idea, but I also consider myself an advanced average Perl programmer
    (that is, certainly not near guru status) and so I probably reflect more
    closely what the average and newbie programmers will have seen
    documented and the reasons behind it. I also think Randal's example
    usage while perfect is intimidating to a new or average programmer,
    there is just an extra call going on there that to someone that
    understands it, it doesn't matter, but to a novice it is something that
    doesn't look quite right, so "hiding" the same thing in the constructor
    is just the easy, lazy (in the bad way) approach for the more advanced
    author of the module. In the above I am referring to:

    my $new_obj = ref($obj)->new;

    The indirection is difficult to read at first so back loading it is just
    easier for the user, but as Randal points out is not forcing them to
    explicitly ask for what they want, where as the above is, and some of us
    prefer that.

    However I don't feel like running out and updating all of my modules,
    but I am going to change my templates ;-)....

    So what would it take to get Randal's view at least added to the docs,
    and a good description of why that view is held?

    I do have to differ with the opinion about new, if you really are just
    constructing an object then to me it still makes sense as a name, but in
    the case of DBI you are constructing an object *and* performing an
    action, so the 'connect' name makes sense. To me it would also make
    sense if there was (and maybe there is):

    my $dbi = new DBI;
    my $dbh = $dbi->connect;

    Because in this case you are *just* constructing an object, and then
    *just* connecting... But this assumes you throw out the history of the
    corruption of the name 'new' both as a cloning method and as "let's do
    more than just create an object, lets also connect to a server, read a
    file, etc." which somehow I don't think Randal will let us ;-) (and he
    probably is right not to)....

    Just my ranting on the subject....

    http://danconia.org

  • Next message: Chris McMahon: "No dice;details . RE: run in background from qx//?"

    Relevant Pages

    • Re: constructor
      ... void foo() ... you didn't call a constructor from main. ... Yes, of course it can be called, but not by the programmer. ... that you're explaining incorrect things to novice programmers? ...
      (comp.lang.cpp)
    • Re: Default constructor
      ... > 2) Automatic default constructor inserted even if the programmer provides ... Now the client can declare objects of this ... the programmer thought creating an object with no initializing parameters ...
      (comp.lang.cpp)
    • Re: Overflow or underflow in the arithmetic operation when showing form AGAIN?
      ... When are you calling FixFPU? ... between the start of the constructor and when the font is created. ... I contacted the programmer and he told me "XXX ... > Support AT NOSPAM Zerama DOT NET ...
      (microsoft.public.dotnet.framework.drawing)
    • Re: base/derived name unhiding but with ctors
      ... If e.g. it is a pointer to a function ... pointer to a constructor, because you cannot call a constructor, ... and that can't be explicitly done by the programmer. ... destructor calls", because a destructor can't be called, just like a ...
      (comp.lang.cpp)
    • Re: Instantiate child object from inside parent constuctor?
      ... I hadn't considered the recursion problem. ... class for ease of access to child classes and...duh...created deep ... >>Is it possible to instantiate a child class within the constructor of its ... >>Class DBI extends DB { ...
      (comp.lang.php)