[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dynamic vs. static typing
Anton van Straaten wrote:
> On 26 Nov 2003, at 7:27 PM, Peter van Rooijen wrote:
> > I'm talking about the situation, which is very common for me, that I
> > have something extra I would like to say (in code), about the message
> > I am sending, while I might not have anything I'd like to say about
> > the variable I'm sending the message to.
> > For instance, I might want to send #size to myObject (in
> > Smalltalk: myObject size), and I know that I mean #size as in
> > "the number which is the same as the number of objects that
> > would be enumerated if I did an enumeration". So, the #size
> > I am sending is #size with the semantics as defined in the
> > Enumerable type.
> > In fantasy-Smalltalk, I would perhaps write myObject Enumerable#size.
> > Important to note here that this is not a cast of the expression
> > referencing the variable; I am NOT ready to say anything about the
> > type of the variable myObject. It could be anything. I'll probably
> > attach a collection to it (and the collections I'm going to attach
> > are certainly going to be enumerable), but I'll decide later and
> > I might change my mind. I might never provide a type for myObject.
> > But I do know that right here I want Enumerable#size.
> > Maybe this sounds really strange. Maybe it is :-).
> No, it's not strange at all. What you are describing are interfaces or
> typeclasses, terminology depending on language. Their exact behavior
> depends on the language/typesystem. Your fantasy-Smalltalk is actually
> suspiciously similar to Java.
> You say that "I am NOT ready to say anything about the type of the variable
> myObject", but really that's incorrect. You *are* making an assumption
> about the type of the variable: you are assuming that it will refer to an
> object that supports an Enumerable interface. The object may also support
> other interfaces, but that's OK, if you have a good type system.
> A number of languages implement such interfaces explicitly in some form. In
> Java, they're called interfaces. In Haskell, the equivalent is typeclasses.
> C++ also supports them. Those are all statically typed languages, but some
> dynamically typed languages support them also, including some Scheme object
> systems. Even (some) Smalltalks have them:
> Unfortunately, traditional class-based OO tends to encourage a mindset in
> which the type of an object is considered to be equivalent to its class.
Nice analysis, Anton. I'd like to add that Bill Joy and I explicitly
tried to fight this mindset when we wrote section 4.5.5 of JLS1, titled
"Variables Have Types, Objects Have Classes". (It would have been more
complete to write "Expressions Have Types, Objects Have Classes" but we
knew people focus most on types in connection with declaring variables.
The section itself discusses both variables and expressions.)
"Every object belongs to some particular class. ... This class is
called the _class of the object_. ... An object is said to be an
instance of its class and of all superclasses of its class.
"(Sometimes a variable or expression is said to have a "run-time type"
but that is an abuse of terminology; it refers to the class of the
object referred to by the value of the variable or expression at
run time ... Properly speaking, type is a compile-time notion.
A variable or expression has a type; an object or array has no type,
but belongs to a class.
"The type of a variable is always declared, and the type of an expression
can be deduced at compile time. The type limits the possible values
that the variable can hold or the expression can produce at run time.
"Even though a variable or expression may have a compile-time type
that is an interface type, there are no instances of interfaces.
A variable or expression whose type is an interface type can reference
any object whose class implements that interface."