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~
