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