Salvatore <sa************ *@wanadoo.fr> wrote:
Thank's everybody :-)
Here is a type définition I've found on the net which I agree with :
Attribute of a variable which determines the set of the values this
variabe can take and the
operations we can apply on it.
Hmmm -- that doesn't work very well for languages in which "a variable"
is just "a name", because we cannot apply any operations at all on THE
NAME -- we apply operations on the OBJECT to which the name refer. This
issue arises with both languages where names "can take" any object, like
Python, and ones where the compiler infers the subset (type) of objects
that each name "can take", like Boo.
Moreover, asserting that 'type' is an attribute of a variable means, for
example, that a function's return-value, not being a variable, has no
type -- that really makes no sense. And similarly for other
expressions; e.g., consider, in Java, something like...:
( (Fooable) zip() ).getFoo() + ( (Barable) zop() ).getBar()
no variables in sight, yet a lot of types in Java's normal sense -- the
types of whatever objects zip() and zop() return, the (Fooable and
Barable, respectively) types after the cast, the type of whatever getFoo
and getBar return, and the type of their sum...
Saying that an _object_ has a type thus makes more sense (even in Java
and similar languages) than considering type to be an "attribute of a
variable" -- *in addition* to objects, which have types, other language
constructs, depending on the language, may or may not be imbued with
type-constraints, be that declaratively (as, say, in Java), by compiler
inference (as, say, in Boo), or by other means yet such as stropping
(e.g., in Perl, you can tell from just looking at the name whether a
variable refers to a scalar, $something, an array, @something, or a
hash, %something -- in Python, Java or Boo you can't tell from just the
name, but rather must find a declaration [Java], assignment [Python] or
use [Boo] to let you read or infer the "scalar vs array" type issue).
Alex
