I saw this module come across recently: MooseX::Role::UnsafeConstructable

I immediately thought of a few use-cases where I want to instantiate an object from, say, a database row but having init_arg => undef, in my Moo code would prevent that.

As it turns out, it is fairly simple to create a Moo::Role that can provide a new method, possibly named restore that can ignore the init_arg directive and allow one to instantiate a Moo object from a hash or hashref that would otherwise be blocked. A side benefit is that such a method could still call builders and whatnot if needed for attributes that were not stored in the database row.

My questions are these: a) does anyone else have a similar use-case where it would be handy to do something like my $obj = MyClass->restore( $db_rowref );, bypassing init_arg restrictions, and b) what would be the correct name for such a Role? (I really think "UnsafeConstructable" is a bad choice.)

I realize there are a few (or more) warts on this, especially where init_arg is used to rename an attribute. I would love to hear thoughts on what one would expect to happen in those cases.

You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

Replies are listed 'Best First'.
Re: RFC: MooX::Restore
by Anonymous Monk on Oct 29, 2014 at 06:22 UTC

    :) Those dogs don't hunt :)

    MooseX::Role::UnsafeConstructable should have been called ... Untyped, Untypecheck, NoTypeCheck

    MooX::Restore is equally bad, should be called ... bypass_constructor new_from_hashref

    :) coming up with bad ones is easier :)

      I think you almost got there: MooX::BypassInitArg

      You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.