Re: checking consistency between attributes

Chris,

Yes, the key is to figure out the best place to add this feature.  
Trigger fires after the assignment has been made, which in this case  
is too late. We had talked about a multi-phase trigger which would  
allow a "before" and "after" options, like so:

has foo => (
   is => 'rw',
   ...
   trigger => {
     before => sub { ... },
     after  => sub { ... },
   }
);

this would allow the backward compat to be handled when trigger is a  
CODE ref, but the new feature could be handled when it is a HASH ref.  
This is not all that different then the inflate/deflate that  
DBIx::Class offers.

The idea would be that the "after" would do the same as the normal  
trigger, and the "before" would get the same arguments as the normal  
trigger except the assignment would not have happened yet. The tricky  
bits are:

- do we make the "before" trigger return a value for us to assign?
- do we make the "before" trigger actually do the assignment?
- what happens if an exception is thrown inside the "before", do we  
catch it?
- how would you/should you be able to -- indicate failure or some  
kind in before?

THoughts?

- Stevan



On Jul 15, 2008, at 4:55 PM, Christopher Brown wrote:

> 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~
>
>