Class::Std - how to indicate construction failure

[Dave Weaver]

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() ?

 

[Anno Siegel]

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

 

[Anno Siegel]

Dave Weaver ([email protected]) wrote on MMMMDCVII September MCMXCIII in
<URL: 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