in reply to Re^2: Thoughts on new 'class' OO in upcoming perl
in thread Thoughts on new 'class' OO in upcoming perl

How do you prevent your OO system from throwing in case a mandatory parameter is missing and convince it to return undef instead?

How do you prevent bless() from throwing in case a mandatory parameter is missing, and convince it to return undef instead?

my $data = undef;
my $object_or_undef = bless( $data, 'My::Class' );

[download]

(The above will throw an exception.)

The answer is you don't even try to stop bless bless from throwing. You wrap it in sub new { ... } so you have more control over how bless is called:

package My::Class {
  sub new {
    my ( $class, $data ) = @_;
    return undef unless ref $data eq 'HASH';
    bless $data => $class;
  }
}

my $data = undef;
my $object_or_undef = My::Class->new( $data );

[download]

Similarly, if you don't want core OO's new to throw an exception when mandatory paramaters are missing, you wrap it in another method.

Hire me at Toby Ink Ltd or Join my OnlyFans

Replies are listed 'Best First'.
Re^4: Thoughts on new 'class' OO in upcoming perl
by Jenda (Abbot) on Apr 10, 2023 at 11:20 UTC

    bless() is an implementation detail, new() is the agreed upon name of the method you are supposed to call.

    Jenda
    1984 was supposed to be a warning,
    not a manual!

[reply]
[d/l]
[select]

      Only by convention. Conventions can be changed.

      To an extent, Moose has already changed that convention. The new method generated by Moose can be a little inflexible, so many people write a wrapper constructor around it — new_from_foo or new_with_bar or whatever — and document that this should be used rather than calling new directly.

      Hire me at Toby Ink Ltd or Join my OnlyFans
[reply]
[d/l]
[select]

        That gradual change is something I'm not completely happy with - only I fail to come up with a better solution.

        Moose did change the convention only a bit: It offers its own new with a key/value API, but also has BUILDARGS and other magic like coercions which allow to mimic practically any existing constructor API. Corinna will not provide the same helpers for backward compatibility. I guess I can live with that, because during the last decade or so I adopted the key/value style anyway.

        The "bless vs. new" thing has hit me a lot harder in situations where serialization of objects is needed. Even complex Moose objects can be built from e.g. JSON or YAML strings, and then blessed into the appropriate class. This is no longer possible with Object::Pad or Corinna: You can (re)create their objects only by calling new, undergoing the same API restrictions and validations as for fresh objects. If an object, during its lifetime, achieves a state which is not available by calling new, then... object persistence gets a lot harder.

[reply]
        At $job - 1, we used Moose, but new_from_foo in a Class wouldn't have passed a code review. The correct way was to introduce a Class::Builder::FromFoo which took foo as the constructor parameter and provided a build method; thus following the Builder pattern.

        I'm not sure there's a similar pattern for with_bar, I've never needed it there.

        map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
[select]

In Section Meditations