Hi Sawyer,
Thanks for the reply.
Succinctly.
Given a class X and class Y.
An object in class X may be promotable to class Y, depending on internal
values.
How would you test whether an object can be promoted? In class X or
class Y or elsewhere?
$objectX = ClassX->new(params ...) ;
$objectX->canPromoteToClassY
or
$objectX = ClassX->new(params ...) ;
eval { $objectY = ClassY->new(param => $objectX) }
or ....
Peter
On Wed, 2011-10-12 at 11:08 +0200, sawyer x wrote:
> Hi Peter.
>
> That was a lengthy email and it would be easier for me to simply reply
> to all instead of picking specific parts. Unfortunately my email would
> probably come out lengthy as well.
>
> I think the examples you gave from Moose were simply to showcase
> specific features instead of a proper design. For example, to show how
> "message" works. If you want an example of how you would handle an
> error, Moose::Unsweetened shows how to handle dates and even
> emails[1]. They indeed use a subtype there to do the validation.
>
> I think there are a few flaws in your design, mainly:
> 1. you're using an object-scoped error indicator (not a good idea!)
> 2. you're using read-write attributes which add complexity
> 3. you're pushing the checks yourself instead of letting the code do
> it
> (which also makes the code less self-descriptive)
> 4. you're not able to make use of lazy attributes because you're
> forcing it at build-time
>
> What I would do is:
> 1. set up a role for each type, just to make it cleaner
> (MyApp::Types::Email)[2]
> 2. create "Email" as a subtype inside that role, and put all the
> validation there
> 3. add coercing abilities to convert other values into email (for
> example a string, a scalar reference, a list, etc.)
>
> I'd prefer to have very strict attributes and in case I'm getting the
> input in run-time to create the new object, I'd want to add another
> validation layer there. Why? Because there are two scenarios to
> account for:
> 1. I wrote an object, someone is now using it when they start their
> app. They're feeding the CLI to the object, so you don't have a space
> in which to put validation - it means it *has to be* in the attribute.
> 2. I wrote an object, someone is now using it way after they start the
> app, and they don't want it to crash everything. In that case, there's
> a space where they (or I) can add another validation layer to make
> sure they don't create an object with invalid data. In that case the
> check will be outside the object, before the object is being
> constructed and not in the object.
>
> Personally I like objects that blow up when you don't set them up
> properly. It ensures no surprises later on.
> (and I'm not a try/catch type of guy!)
>
> On a different note, I did have an idea on how to patch Moose in a way
> that will allow a user to handle problems whenever they happen via
> callbacks instead of crashing everything, but due to time limitations
> and the fear of upper scoping changes which isn't possible without
> continuations (which I'm not an expert of) make me believe I won't
> have this pinned down any time soon. Sorry. :)
>
> [1] https://metacpan.org/module/Moose::Manual::Unsweetened
> [2] there are already a few prepared subtypes people have uploaded to
> CPAN under MooseX::Types::* - take a look specifically at
> MooseX::Types::Email
> (https://metacpan.org/module/MooseX::Types::Email).
>
> _______________________________________________
> Perl mailing list
> [email protected]
> http://mail.perl.org.il/mailman/listinfo/perl
_______________________________________________
Perl mailing list
[email protected]
http://mail.perl.org.il/mailman/listinfo/perl
