I'm starting to really like this dynamic typing world!
If you want the ugly stuff, you write it... I think I`ll wait the first time I get a bug in the system caused by wrong type parameters, anyway the nice thing is that I can choose if I want it or not! I have never tought about the XXX-Like concept, but, there is the charm of smalltalk!
[]'s Kalecser
On 9/5/05, Alan Lovejoy squeak-dev.sourcery@forum-mail.net 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
squeak-dev@lists.squeakfoundation.org