One perspective on Traits:
   "A Trait can be used as an interface definition with default methods"
This use of Traits :
¤ is independent of class
¤ can be used as a high level hint as to message semantics
¤ can preserve encapsulation because class-dependent details can be hidden 
in class specific sub-methods
¤ does not preclude other uses of Traits
¤ need not be compulsory everywhere
---
I once compared using Java and Smalltalk collection classes. The Java 
versions filled about twice as many lines; the code being cluttered with 
type information that almost completely hid the what the code actually did.

I once reviewed a large number of methods in a commercial Smalltalk 
product. I found many type errors. Almost all were trivial, the most usual 
being that a method returned a wrong type on error (typically nil or self). 
I did not find any deep, logical type errors.

I have limited experience with Java, but find that I have to use type 
casting whenever the logic gets complicated. So the Java type system helps 
me in the trivial cases but not when the program gets complex.

I concluded that Java helped me find trivial errors, but camouflaged the 
hard ones. Smalltalk  code is easier to read so it is easier to avoid the 
deep type errors. I prefer Smalltalk when I have to make a choice.

I currently believe we need some kind of type system in Squeak. It should 
probably be voluntary, to be used at the programmer's discretion. It should 
express semantic intent as well as signature. It should honor encapsulation.

It could be fruitful to explore Traits as a typing system to be used to 
clarify complex logic and to be ignored in simple cases. For example, it 
could be used to define the provided interfaces of a Tweak Island, giving a 
high level documentation of what the island does as well as enabling 
powerful tools for island composition. It could also be used to define the 
APIs of a package. (Many people in the Squeak community use the term "API" 
to mean something that does not include an explicit interface definition. 
This usage is very confusing to the uninitiated).

Cheers
--Trygve



At 21:52 05.09.2005, Alan wrote:
>Kurtz Kalecser>" So, if the user create a EntityMock with any other object
>than an entity should the system warn him?"
>
>In the absence of a system or application architecture, there can be no
>well-defined "right" answer to your question.  You have to devise an
>architecture to serve as a context for motivating a "right" answer.
>
>For example, the architecture must define the precise meaning of "compatible
>type."  Does "type compatibility" mean that a value is an instance of a
>particular class, or an instance of a class in a particular class
>inheritance hierarchy, or an instance of a class that responds to a
>particular message or set of messages? The architecture must assign
>architectural roles and responsibilities for detecting errors (such as
>typing errors,) for reporting errors and for handling errors.  It may also
>need to define an ontology of error types, and may need to assign error
>detection/reporting/handling responsibility as a function of the ontological
>type of an error.
>
>It is part of the design philosophy behind Smalltalk that the responsibility
>for such architectural decisions rests properly with the programmer, and not
>with the language designer.  Static type checking imposes an architectural
>decision on application programmers that is provably inappropriate for many
>cases.  Worse, it violates encapsulation, because it exposes the
>implementation of an object outside the object's "black box" encapsulation
>of its behavior.  And even worse, it confuses the value (state and behavior)
>of an object with the variables that reference it.  A variable is not the
>value (or object) it references. (Note that in some languages, even
>variables are first class objects, separate from the objects they
>reference.)
>
>What's important about a variable is the semantic role it plays in a
>computational process.  The implementation type of the values it references
>ought to be fully encapsulated, so that an instance of any
>semantically-equivalent type can be referenced by the variable.
>
>However, even type specifications that only specify message signatures (e.g,
>Java interfaces) do NOT define a semantic role, nor do they usually specify
>only those messages actually sent to the value(s) referenced by any
>particular variable (and the latter flaw is why those academics who remain
>seriously committed to static type checking now generally prefer type
>inferencing approaches.) But even type inferencing does not address the
>issue of the difference between a semantic role and a set of message
>signatures.
>
>In the end, only the programmer can and should be responsible for the
>semantic correctness of his code. If the programmer cannot be trusted to get
>the types right, how can he be trusted to get any of the other attribute
>values and/or behaviors encapsulated by his program's objects right? The
>correctness of the value of "aRectangle origin x" is neither more nor less
>important than the correctness of the value of "aRectangle origin class."
>If the value of the former can adequately be managed dynamically, why not
>also the value of the latter?
>
>
>--Alan


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway