A few questions regarding typing. (first some assumptions/axioms)
Axiom #1: perl6 will enable programs to be more explicit about the typing
of variables -- even allowing them to specify dynamic-ish properties about
the values in those variables.
Damian's Attribute::Types has examples like this...
my %handler : CODE; # Entries can only store sub refs
my $arr : ARRAY; # Can only store array ref
my $score : NUMBER(0.1..9.9); # Can only store a num between 0.1..9.9
my $guarded : Type(&odd); # Can only store values for which
# odd($value) returns true
while Exegesis 2 has examples whose syntax is probably a little closer to
what will finally be in perl6...
my int ($pre, $in, $post) is constant = (0..2);
Axiom #2: perl6 will allow more more robust subroutine prototyping for
compile time / run time type checking.
>From Exegesis 2...
sub insert (HASH $tree is rw, int $val) { ... }
sub search (HASH $tree is rw, *@_) { ...; return $tree }
(which will presumably cause a fatal error if called as insert(1,"foo")
Quandary #1: How "deep" of type specifications should / will perl6 allow?
For example, could something like this work?
my ARRAY(int(0..9)) $ref # $ref can only store an array ref
# ...and that array can only hold ints
# ...and those ints must be between 0 & 9
Quandary #2: Should / will subroutine prototyping provide any support
for specifying the return type? perhaps...
sub search (HASH $tree is rw, *@_) HASH { ...; return $tree }
If so, this opens up all sorts of questions ... the influence of
calling context (ie: "wantarray") comes to mind.
Quandary #3: Should / will perl6 support polymorphic typing? In the past,
it really hasn't mattered -- but as perl begins to support stricter typing
(if you want it) people may find themselves having to choose between
strongly typing their subroutines to make their code more explicit to
callers, or excluding typing info to make them useful in more situations.
All of these quandary's occurred to me as I started to wonder how you could
write a reusable Tree class whose insert/search/delete methods could be
prototyped to require an argument of the type specified when the Tree
was constructed. (without requiring the class to do it's own type
checking)
--
-------------------------------------------------------------------
"Oh, you're a tricky one." Chris M Hostetter
-- Trisha Weir [EMAIL PROTECTED]
