I'm starting to really like this dynamic typing world!<br>
<br>
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!<br>
I have never tought about the XXX-Like concept, but, there is the charm of smalltalk!<br>
<br>
[]'s Kalecser<br><br><div><span class="gmail_quote">On 9/5/05, <b class="gmail_sendername">Alan Lovejoy</b> <<a href="mailto:squeak-dev.sourcery@forum-mail.net">squeak-dev.sourcery@forum-mail.net</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Kurtz Kalecser>" So, if the user create a EntityMock with any other object<br>than an entity should the system warn him?"
<br><br>In the absence of a system or application architecture, there can be no<br>well-defined "right" answer to your question. You have to devise an<br>architecture to serve as a context for motivating a "right" answer.
<br><br>For example, the architecture must define the precise meaning of "compatible<br>type." Does "type compatibility" mean that a value is an instance of a<br>particular class, or an instance of a class in a particular class
<br>inheritance hierarchy, or an instance of a class that responds to a<br>particular message or set of messages? The architecture must assign<br>architectural roles and responsibilities for detecting errors (such as<br>typing errors,) for reporting errors and for handling errors. It may also
<br>need to define an ontology of error types, and may need to assign error<br>detection/reporting/handling responsibility as a function of the ontological<br>type of an error.<br><br>It is part of the design philosophy behind Smalltalk that the responsibility
<br>for such architectural decisions rests properly with the programmer, and not<br>with the language designer. Static type checking imposes an architectural<br>decision on application programmers that is provably inappropriate for many
<br>cases. Worse, it violates encapsulation, because it exposes the<br>implementation of an object outside the object's "black box" encapsulation<br>of its behavior. And even worse, it confuses the value (state and behavior)
<br>of an object with the variables that reference it. A variable is not the<br>value (or object) it references. (Note that in some languages, even<br>variables are first class objects, separate from the objects they<br>
reference.)<br><br>What's important about a variable is the semantic role it plays in a<br>computational process. The implementation type of the values it references<br>ought to be fully encapsulated, so that an instance of any
<br>semantically-equivalent type can be referenced by the variable.<br><br>However, even type specifications that only specify message signatures (e.g,<br>Java interfaces) do NOT define a semantic role, nor do they usually specify
<br>only those messages actually sent to the value(s) referenced by any<br>particular variable (and the latter flaw is why those academics who remain<br>seriously committed to static type checking now generally prefer type
<br>inferencing approaches.) But even type inferencing does not address the<br>issue of the difference between a semantic role and a set of message<br>signatures.<br><br>In the end, only the programmer can and should be responsible for the
<br>semantic correctness of his code. If the programmer cannot be trusted to get<br>the types right, how can he be trusted to get any of the other attribute<br>values and/or behaviors encapsulated by his program's objects right? The
<br>correctness of the value of "aRectangle origin x" is neither more nor less<br>important than the correctness of the value of "aRectangle origin class."<br>If the value of the former can adequately be managed dynamically, why not
<br>also the value of the latter?<br><br><br>--Alan<br><br><br><br></blockquote></div><br><br clear="all"><br>-- <br>Tis the business of little minds to shrink, <br>but he whose heart is firm, and whose conscience approves his conduct,
<br> will pursue his principles unto death.<br>Thomas Paine