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
|