First of all: OK - I understand that this was the official interpretation. This is enough for me for continuing my work.
But see below for some more 'philosophical' notes. On Wed, Apr 29, 2009 at 2:45 PM, Stevan Little <stevan.lit...@iinteractive.com> wrote: > > 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. > I was not talking here about variables (where the 'statically typed' term could be applied) I was talking about values. > 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. > Hmm - ok so my intuition of types and subtypes is that the two sentences hold: 1. If a value has a type A that is a subtype of type B - then this value is of type A 2. Every type is a subtype of itself Now take DateInThePast - the same value (lets say 29th of April 2009) can at one point have that type and at another point in time it will not have that type. The point is that in the Moose type system these sentences don't have any meaning at all - because it is not the value that has the type. > - 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. The same as above - I am not talking about variables but about values. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
