type checking

Kalecser Kurtz kalecser at gmail.com
Mon Sep 5 20:07:09 UTC 2005


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 at 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
> 
> 
> 
> 


-- 
Tis the business of little minds to shrink, 
but he whose heart is firm, and whose conscience approves his conduct,
will pursue his principles unto death.
Thomas Paine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050905/7372afbd/attachment.htm


More information about the Squeak-dev mailing list