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~
