Re: how to handle error with type constraint
Hi John,
Thanks for you reply.
My example is just academic, as I am only starting playing with Moose.
My application will have to issue reports and retrieve some indicators on
various equipments on a network backbone.
I will to open tcl, and snmp session for each equipment. Now, my plan is to
initiate those sessions, set some environment variables, perform some basic
task while the object get instantiated.
I am trying to figure out the best way to encapsulate those sessions and
report some failure to the caller.
If someone has some good advises on how to achieve this...
Regards,
Vincent.
2008/9/22 John Napiorkowski [EMAIL PROTECTED]
--- On Mon, 9/22/08, vincent roudil [EMAIL PROTECTED] wrote:
From: vincent roudil [EMAIL PROTECTED]
Subject: how to handle error with type constraint
To: moose@perl.org
Date: Monday, September 22, 2008, 9:40 AM
Hello Moose,
I am just starting to explore Moose. This is probably
something simple, but
I can't figure out the best way to do this.
With the Moose type constraint, I would like to get control
of the error
handling when the type is invalid.
Here is an example.
a class host, with 2 attributes, name and ip_addr, with a
control on the IP
address validity:
# package host.pm
package host;
use Moose;
use Moose::Util::TypeConstraints;
use Regexp::Common qw /net/;
subtype IPAddr
= as Str
= where {/^$RE{net}{IPv4}$/}
= message { 'invalid IP address'};
has 'ip_addr' = (isa = 'IPAddr', is
= 'ro', required = 1);
has 'name' = (isa = 'Str', is
= 'ro', required = 1);
1;
# end package host.pm
The type constraints works fine. Only that when the IP
address is invalid
the program dies, with great verbosity.
I would just like when IP address is invalid, to print a
message in a log
file, and that the creation of the instance fails quietly,
so I could use
the host class like this:
# main.pl:
use host;
my $h=host-new(name='jupiter',
ip_addr='10.10.10.1');
if ($h) {
print $h-name. created successfully with the IP
address .$h-ip_addr;
}
If someone could point me to the right direction, that
would be great.
Thanks in advance.
Vincent.
Hey,
For me I would try to clearly separate my business logic validation needs
from type constraints on my storage classes or domain model. There are a
few reasons for this, mostly having to do with separation of concerns and
the fact that incoming user data will likely have a few different validation
paths at some point. Also you can create reuseable validation classes.
I don't know your exact problem domain, but for me as a web developer I am
doing a lot of validation and error messaging for incoming post params. For
that I use Data::FormValidator, and make as many custom classes as I need.
Then I'd try to have some sort of workflow on the incoming params to first
validate and then if valid pass on to the domain model. I try to see my
type constraints as a sort of last chance to catch problems before they
generate a hard error in my database.
The only downside to my method is that you end up rewriting validation code
a few times. I know there are new tools cropping up to help with this,
Reaction and Ernst from what I understand are attempts to let you infer your
business validation needs from the type constraints on your storage object,
but yet retain enough flexibility when your business validation needs
different from the domain constraints. I haven't had time to play with
these yet, but maybe someone else on the list will jump in.
Until then I recommend having user input validation as a first layer before
it tries to hit your Moose attributes.
my $0.02
John Napiorkowski
Re: Multiple coercions ?
On Wed, 24 Sep 2008, Alexis Sukrieh wrote: Charles Alderman a écrit : This works for me: [...] I've just ran your test-script, and I got the same error. This is an Ubuntu 8.04 system, the Moose that comes with is 0.31, maybe this is a bug of that version? Ok, Moose _0.58_ was just released, and you're reporting bugs in 0.31, which was released approximately 10 months ago? Why? -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: Multiple coercions ?
Meta questions: Is the purpose of this list to only report bugs or discuss design questions? Or is it to help out Moose users? Should the list be split into moose-dev and moose-users? Perhaps if a user happens to overlook the version they're running before asking a question, it could be accepted as a newbie question in a moose-users list conversation. Thanks, Charles Alderman - Original Message - From: Dave Rolsky [EMAIL PROTECTED] Sent: Wed, 24 Sep 2008 10:14:49 -0500 (CDT) Re: Re: Multiple coercions ? Ok, Moose _0.58_ was just released, and you're reporting bugs in 0.31, which was released approximately 10 months ago? Why? -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: Multiple coercions ?
Charles Alderman a écrit : Perhaps if a user happens to overlook the version they're running before asking a question, it could be accepted as a newbie question in a moose-users list conversation. It's really funny how you can be flagged newbie at the first mistake you make. Indeed, I totally forgot that Moose grows so quickly that my fresh _stable_ Ubuntu system would be far too old for a bug-proof version of Moose. Indeed, this is my fault. I apology for that. But please don't start to judge people with the first email/mistake you see from them. You don't want to do that. Alexis.
Re: Multiple coercions ?
--- On Wed, 9/24/08, John Napiorkowski [EMAIL PROTECTED] wrote: From: John Napiorkowski [EMAIL PROTECTED] Subject: Re: Multiple coercions ? To: Charles Alderman [EMAIL PROTECTED] Date: Wednesday, September 24, 2008, 12:00 PM --- On Wed, 9/24/08, Charles Alderman [EMAIL PROTECTED] wrote: From: Charles Alderman [EMAIL PROTECTED] Subject: Re: Multiple coercions ? To: moose@perl.org Date: Wednesday, September 24, 2008, 11:34 AM Meta questions: Is the purpose of this list to only report bugs or discuss design questions? Or is it to help out Moose users? Should the list be split into moose-dev and moose-users? Perhaps if a user happens to overlook the version they're running before asking a question, it could be accepted as a newbie question in a moose-users list conversation. Thanks, Charles Alderman Right now we have IRC channels split this way. To be honest, the IRC gets a lot more traffic than the mailing list in terms of discussion and help. This makes sense to me since Moose is rapidly growing and also I've noticed that for Perl there have been a preference to IRC over mailing lists and other types of dicussion (blogging, etc). There is a good part to this, since IRC is immediate, but of course there is a downside since IRC is very unstructured and it's not searched by the big search engines, which I think hurts us PR wise. Try irc://irc.perl.org#moose for general moose questions and irc://irc.perl.org#moose-dev for moose new development. Peace John Napiorkowski - Original Message - From: Dave Rolsky [EMAIL PROTECTED] Sent: Wed, 24 Sep 2008 10:14:49 -0500 (CDT) Re: Re: Multiple coercions ? Ok, Moose _0.58_ was just released, and you're reporting bugs in 0.31, which was released approximately 10 months ago? Why? -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: Multiple coercions ?
On Wed, Sep 24, 2008 at 11:01 AM, John Napiorkowski [EMAIL PROTECTED]wrote: course there is a downside since IRC is very unstructured and it's not searched by the big search engines, which I think hurts us PR wise. IRC also tends toward a particular culture (if I may dignify it with that term) which I think hurts PR-wise, too.
Re: Multiple coercions ?
I apologize, I don't mean any offense by newbie. It was not my intent to label you that way. I was only referring to the category of questions that are easy to resolve. In regards to Moose, I consider myself a newbie, as opposed to the experts who created it and contribute to it. Thanks, Charles Alderman - Original Message - From: Alexis Sukrieh [EMAIL PROTECTED] Sent: Wed, 24 Sep 2008 17:41:02 +0200 Re: Re: Multiple coercions ? Charles Alderman a écrit : Perhaps if a user happens to overlook the version they're running before asking a question, it could be accepted as a newbie question in a moose-users list conversation. It's really funny how you can be flagged newbie at the first mistake you make. Indeed, I totally forgot that Moose grows so quickly that my fresh _stable_ Ubuntu system would be far too old for a bug-proof version of Moose. Indeed, this is my fault. I apology for that. But please don't start to judge people with the first email/mistake you see from them. You don't want to do that. Alexis.
Moose::Meta::Role::rename_attribute
Hi All, Decided to ask this one of the list rather than #Moose. Is there / should there be a *Moose::Meta::Role-rename_attribute* method? It is easy to change the guts of an attribute using the *has + *syntax, but I have not found an official way to change the name of an attribute. I am wondering if Moose::Meta::Role should contain a rename_attribute method that does something like the following: my ( $self, $old_name, $new_name ) = @_ ; my $attr = $self-meta-get_attribute( $old_name ); $self-add_attribute( $new_name, $attr ); $self-remove_attribute( $old_name ); Thoughts, Chris
Re: Moose::Meta::Role::rename_attribute
--- On Wed, 9/24/08, Christopher Brown [EMAIL PROTECTED] wrote: From: Christopher Brown [EMAIL PROTECTED] Subject: Moose::Meta::Role::rename_attribute To: moose@perl.org Date: Wednesday, September 24, 2008, 8:50 PM Hi All, Decided to ask this one of the list rather than #Moose. Is there / should there be a *Moose::Meta::Role-rename_attribute* method? It is easy to change the guts of an attribute using the *has + *syntax, but I have not found an official way to change the name of an attribute. I am wondering if Moose::Meta::Role should contain a rename_attribute method that does something like the following: my ( $self, $old_name, $new_name ) = @_ ; my $attr = $self-meta-get_attribute( $old_name ); $self-add_attribute( $new_name, $attr ); $self-remove_attribute( $old_name ); Thoughts, Chris Chris, To be honest I don't think this should be a function of Role, since in my mind I see a Role as being something that defines a package of behavior, and it really should not be mucking about with the attributes or methods of a class that consumes it, unless via one of the clearly established means, such as the advice modifiers around, before, etc., and in which case any so modified methods should required. So I think that doing this could well be improper separation of concerns. I guess something like this could have some use as a utility class. --John Napiorkowski
