On Apr 29, 2009, at 5:48 AM, Zbigniew Lukasiak wrote:
It seems that in the Moose terminology a Type is just a constraint
with a name. This is different from other languages where the type of
a value does not change in time or in relation to the whole system.
You can copy the value and be sure that the copy has the same type you
can wait and check the value after some time and it's type would not
change, but if a value type is defined by it passing a constraint -
then these invariants do not hold. For example think about a
constraint that checks if a date is in the past.
Actually they are called "TypeConstraints" in the docs, sometimes
shorten to just "types" for convenience, but we make no claims that
this is a full fledged type system (http://search.cpan.org/~drolsky/Moose-0.76/lib/Moose/Util/TypeConstraints.pm#Important_Caveat
).
The other languages you describe are statically typed languages
(Haskell, OCaml, Ada) where the compiler has sufficient information to
perform an analysis of all variables at compile time and assure that
their type usage stays correct. Quite often actually these languages
will actually discard type information once it has been statically
verified at compile time and not actually perform any runtime checks
(no need too, it is already known it is correct). I personally would
love to be able to do this in Perl, but is probably not possible
without re-writing parts of the core interpreter.
What Moose aims to provide is two things:
- A flexible and extensible way to compose types and subtypes
This is the "Type" part of the "TypeConstraints". This system is
modeled partially on Perl 6 but largely on more formal type systems
like Haskell and OCaml. The big difference between this and an OCaml/
Haskell type system is that Ocaml/Haskell type definitions also
function as type constructors as well as type checkers, ours are just
type checkers.
- A means of using these type constraints for validation
This is the "Constraint" part of the "TypeConstraints". The goal is
help make it easy to use the types you define to check parameters
(using one of the MooseX:: method modules) and/or object slot values
(in core Moose). All type constraints are instances of
Moose::Meta::TypeConstraint or a subclass of that, and they all
respond to the basic ->check($value) method (No magic here folks).
---
So, the way you need to look at this really is not a type system where
types are attached to a given variable for it's entire life, but a
type constraint system where certain values can be checked at runtime
to see if they pass the constraint. In other words, not "real" types.
This is not to criticise this - I understand that it is just a
practical solution - I just want to know if there is a consensus that
it is OK to write Moose types like DateInThePast.
Sure, why wouldn't it be okay?
- Stevan
