Stevan, Benh, Charlie and Moose, My two cents is that ALL Moose users will eventually run into this as It is not too uncommon. Think of all the applications that you use where one of the parameters is interdependent upon another. Personally, I have used both triggers and BUILD, but felt that be a better way. Using BUILD seems like a more general solution, but BUILD separates the check/coercion/constraint logic from the attribute definition. IMHO, a bad thing. My thoughts this been that I have wanted a constraint argument to the 'has' function that would fire the defined subroutine just before the BUILD subroutine. Not sure how that would work or even if that is possible in the given architecture.
Best, Chris What I have wanted is a constraint => argument to has that fires Perhaps there should be a constraint => argument On Tue, Jul 15, 2008 at 9:15 AM, Stevan Little < [EMAIL PROTECTED]> wrote: > Well the idea of a type check/coercion that has access to $self has been on > my mind for a while, but I have not figured out yet. Traditionally in most > type systems, especially those which are done at compile-time, you don't > have access to other runtime variables. There is a current research path on > something called "Dependent Types" which brings in the notion of values, > however this is some pretty complex stuff and some of it's detractors have > mused that to really type a program fully you would need to execute it at > compile-time, which means you would likely prove it can stop, which gets > into the whole "would a language with dependent types be turing complete > then?" question (which is also where it goes waaaaaaaay over my head too). > > That said, I think we need a better facility then triggers. > > My concern is that putting this into the type system makes it into "action > at a distance" especially when it comes to coercions. It also ties a type > specifically to a class and so removes reusability (good thing, bad thing, > hard to say here). > > Anyway, it is in the back of my head, I have not forgotten about it. Part > of me fears it will require a type system overhaul/re-write though, so it > may not be coming soon. > > - Stevan > > > > > On Jul 15, 2008, at 4:13 AM, benh wrote: > > It seems that at the heart of it it seems that theres a missing event >> that has access to self? My inital though was to just create a type >> that was min, but types loose there context. I've been trying to wrap >> my head around the code for this to see if there was some way to try >> and have some other specified global structure that would still be in >> scope, but I alway get lost in the passing of things when I look at >> the type code. >> >> I was able to trick things out but it requires that most of the 'built >> in' code structure gets re-done in BUILD, thus you have access to self >> and you end up forcing a system where everything passes thru a >> trigger. This allows you to check for any thing, but it does seem like >> much more of a hack then the inital example... >> >> It's a bit tedious so I posted it elsewhere: >> >> http://develonizer.com/svn/misc/min_max.pl >> >> >> >> >> >> On 7/14/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >>> How about this: >>> >>> has 'min' => ( >>> is => 'rw', >>> isa => 'Int', >>> default => sub { NEGATIVE_INFINITY }, >>> trigger => sub { >>> my ( $self, $val ) = @_; >>> carp "min is > max" unless $val <= $self->max; >>> } >>> ); >>> >>> has 'max' => ( >>> is => 'rw', >>> isa => 'Int', >>> default => sub { POSITIVE_INFINITY }, >>> trigger => sub { >>> my ( $self, $val ) = @_; >>> carp "max is < min" unless $val >= $self->min; >>> } >>> ); >>> >>> No BUILD needed. Consistency checked by the triggers whenever min and >>> max >>> are set... >>> >>> Besides defining negative and positive infinity, the only problem I see >>> is >>> if both min and max are set at the same time, as in the constructor. I >>> don't know which error you'd get if the object was initialized like this: >>> >>> my $foo = Foo->new( >>> min => 1, >>> max => -1, >>> ); >>> >>> Charles Alderman >>> >>> ----- Original Message ----- >>> From: Guillaume Rousse <[EMAIL PROTECTED]> >>> Sent: Mon, 14 Jul 2008 23:15:49 +0200 >>> Re: checking consistency between attributes >>> >>> >>> >>> >>> Hello list. >>>> >>>> What's the best way to check consistency between attributes values ? Is >>>> there anything better than a dedicated BUILD method, such as: >>>> >>>> use Moose; >>>> use Carp; >>>> >>>> has 'min' => (is => 'rw', isa => 'Int'); >>>> has 'max' => (is => 'rw', isa => 'Int'); >>>> >>>> sub BUILD { >>>> my ($self, $params) = @_; >>>> >>>> my ($max, $min) = ($self->max(), $self->min()); >>>> croak "max < min" if defined $max && defined $min && $max < $min; >>>> } >>>> -- >>>> Guillaume Rousse >>>> Moyens Informatiques - INRIA Futurs >>>> Tel: 01 69 35 69 62 >>>> >>>> >>> >>> >>> >>> >> >> -- >> benh~ >> > >
