Class::Std - how to indicate construction failure

Discussion in 'Perl Misc' started by Dave Weaver, Apr 12, 2006.

  1. Dave Weaver

    Dave Weaver Guest

    I'm experimenting with using Class::Std to implement 'inside-out'
    objects.

    In the 'normal' style Perl objects, it's traditional for the
    constructor to return undef if the construction fails. In Class::Std
    the user-level meat of the construction phase is put in the BUILD
    method, but in reading the docs I see no way that the BUILD method can
    pass back a failure status (other than by die-ing) to the code that
    wants to constuct the object.

    For example, using old-style Perl objects,

    my $obj = MyFileObject->new({ file => 'test.txt' });

    would return undef if, for example, the passed file couldn't be found.

    What is the correct way to do this construct-time checking using
    Class::Std? Do I have to override new() ?
     
    Dave Weaver, Apr 12, 2006
    #1
    1. Advertising

  2. Dave Weaver

    Anno Siegel Guest

    Dave Weaver <> wrote in comp.lang.perl.misc:
    > I'm experimenting with using Class::Std to implement 'inside-out'
    > objects.
    >
    > In the 'normal' style Perl objects, it's traditional for the
    > constructor to return undef if the construction fails. In Class::Std
    > the user-level meat of the construction phase is put in the BUILD
    > method, but in reading the docs I see no way that the BUILD method can
    > pass back a failure status (other than by die-ing) to the code that
    > wants to constuct the object.
    >
    > For example, using old-style Perl objects,
    >
    > my $obj = MyFileObject->new({ file => 'test.txt' });
    >
    > would return undef if, for example, the passed file couldn't be found.
    >
    > What is the correct way to do this construct-time checking using
    > Class::Std? Do I have to override new() ?


    In _PBP_, section Error Handling, Damian Conway recommends throwing exceptions
    instead of returning special values. So the idea would be to die() in BUILD
    and, if necessary, catch the error through "eval { Class->new(...) }".

    On the other hand, Class::Std is not the only module on CPAN that supports
    inside-out classes, and not necessarily the best one. Last time I looked
    there were Class::InsideOut and Object::InsideOut. Take a look at them
    if they fit your needs better.

    If you are serious about studying inside-out classes you should also
    build at least one small (but more than trivial) class hierarchy directly,
    creator, destructor and all, if only to see what it is the pre-made classes
    save you.

    Anno
    --
    If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers.
     
    Anno Siegel, Apr 12, 2006
    #2
    1. Advertising

  3. Dave Weaver

    Anno Siegel Guest

    Abigail <> wrote in comp.lang.perl.misc:
    > Dave Weaver () wrote on MMMMDCVII September MCMXCIII in
    > <URL:news:443d0223$0$665$>:
    > :) I'm experimenting with using Class::Std to implement 'inside-out'
    > :) objects.


    Hey, a smiley as quotation marker.

    > IMNSHO, I think the best method to learn what 'Inside Out Objects'
    > are is to implement them without modules.
    >
    > Once you know what they're about, you can make a judgement on what
    > you're willing to sacrifice in order to able to use a module.
    >
    > I've looked at several of the modules implemented Inside Out Objects,
    > and I've found them ranging from overly complicated to completely
    > missing the point of Inside Out Objects.
    >
    > :) In the 'normal' style Perl objects, it's traditional for the
    > :) constructor to return undef if the construction fails.
    >
    > Really?
    >
    > I think that constructors should construct, and nothing else. Which
    > means that the only reason the constructor can fail is the program
    > running out of memory. Which is a nontrappable "very fatal error".


    Ah, but he's talking about Class::Std, which doesn't support the
    separation of creation and initialization very well. The question
    was really how to deal with errors in BUILD, which is initialization,
    not creation. Having to deal with run time errors in initialization
    is common.

    On the other hand, having separate ->init and ->new methods (or whatever
    they're called) isn't particular to inside-out classes. Traditional
    classes would benefit from the separation just as well. It isn't
    seen very often, probably because the disadvantages of a combined
    creator/initializer only become apparent with multiple inheritance.

    With single inheritance it is possible to slip by, using the parent's
    ->new to create an object blessed in your class, but initialized for
    the parent. Then you insert your own data into the existing structure,
    (often in rather unclean ways). That gives you another ->new that
    initializes its objects. Only when there is yet another parent class
    to initialize it becomes a problem that you can't do that without
    creating another object.

    Anno
    --
    If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers.
     
    Anno Siegel, Apr 12, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dill Hole
    Replies:
    2
    Views:
    446
    Mike Wahler
    Jul 5, 2003
  2. Peter Jansson
    Replies:
    5
    Views:
    6,391
    Ivan Vecerina
    Mar 17, 2005
  3. Ook
    Replies:
    10
    Views:
    571
  4. Joost Kraaijeveld
    Replies:
    7
    Views:
    1,452
    Triple-DES
    Jan 5, 2009
  5. mlt
    Replies:
    5
    Views:
    996
    James Kanze
    Feb 13, 2009
Loading...

Share This Page