type checking

Matej Košík kosik at fiit.stuba.sk
Mon Sep 5 20:35:03 UTC 2005


Kalecser Kurtz wrote:
> In smalltalk's dynamic typing aproach, do you think it's a good practice 
> to throw errors when the user try to use incompatible types?
> 
> For example:
> 
> - I create a class 'Mock' to mock general objects;
> - I create a class 'EntityMock' that is a Mock, but just to mock 
> Entities, once entities use doesNotUnderstand to resolve some of it's 
> methods;
> 
> So, if the user create a EntityMock with any other object than an entity 
> should the system warn him?
> 
> []'s Kalecser
> 
> -- 
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> 

Maybe also another example why explicit type checking would be too 
restricting. Look at

	False &

method. Should that method done

	[aBoolean isKindOf: Boolean] assert

?

No, definitely not. If the author of that method restricted the usage of 
its method to work only with Booleans, then Fuzzy values wouldn't work

	false & someFuzzy ... should return false.

(If we viewed the & operator is `meet' operator in `lattice')

with isolationistic Booleans. And that would be a shame because Booleans 
might be viewed as special kind of Fuzzies. As it is now, there is 
nothing which could stop you from implementing fuzzies which would work 
with the rest of the system. You could even implement

	Fuzzy
		ifTrue: block1
		ifFalse: block2

method which would realize fuzzy branching, if anyone wanted it (while 
the "old-fashioned" Boolean ifTrue:ifFalse would be 
"crisp-branching")---but I must admit no reasonable utilization comes in 
my mind but that does not mean that someone else couldn't invent one.

:)
-- 
Matej Košík



More information about the Squeak-dev mailing list