On Jul 2, 2009, at 8:11 PM, Jesse Luehrs wrote:
On Thu, Jul 02, 2009 at 04:36:37PM -0400, Stevan Little wrote:
Very good point actually.
I think we should split the categories by their intentions ...
Structural - ArrayRef, HashRef, Number, etc ...
Behavioral - Counter, Queue, Stack, Buffer, etc ...
Now, you could easily argue all around this and blah blah blah (I
WANT
TO PAINT THE BIKESHED RED!). But what I am proposing is that we draw
*our own* distinctions, complete with reasoning to support. And let
me
start the first wave of bullshit here ...
Structural items are ones for whom the underlying value type is the
key
focus. ArrayRef describes the actual data structure used and Number
the
actual value type used. The operations supplied for these Structural
items are basically the core operations that perl supports out of
the box
(with maybe a few additions for convenience).
Behavioral items are one for whom the behavior of the item is the key
focus. Counter is obvious. The Stack item is less obvious unless you
look at it as an ADT (Abstract Data Type) and realize that it really
describes a data structure whose internal implementation is
irrelevant
as long as it provides an expected set of behaviors.
Yes, these lines are blurry. Yes, you could easily argue that
ArrayRef
fits the Behavioral definition and Stack fits the Structural. But who
cares, I think we can make our own distinctions and as long as we
remain
consistent then all the haters can just f*ck off ;)
So... why stop there? Since we're redoing API anyway, what about this
idea: the Structural items described here get their methods stored
directly on the associated TypeConstraint object, and handles just
looks
things up from there. This would make extending quite easy, doing
something like
subtype 'Matrix', as 'ArrayRef[ArrayRef]',
where { ... },
with { lookup => sub {
my ($mat, $i, $j) = @_;
$mat->[$i][$j]
} };
which would make this valid:
has matrix => (
isa => 'Matrix',
handles => ['lookup'],
);
This would simplify the interface too, since users wouldn't have to
think about including traits and whatnot, things would just work.
Thoughts?
-doy
Well, seems like taking it too far to me, at least for core. Because
while interesting, it really blurs the lines between types and
classes. What would this do?
subtype MyMatrix as Matrix where { ... };
Would it "inherit" the methods? Could I override them if I wanted?
Could I call the "super" method? At some point you end up with an
object system within an object system.
The other thing being that you could do all this if you simply made
Matrix an object in the first place.
Now, this all said, I have always thought that some kind of Haskell-
typeclass-ish type thing would be an interesting extension of the
Moose type system. Something that would pretty much work as you
described above.
In short, interesting MooseX:: project I think, but too much for core.
- Stevan
