X-Mailer: ELM [version 2.3 PL0]
Newsgroups: comp.lang.smalltalk
Date:         Thu, 28 Jan 1993 17:22:10 MET
From:         Joerg Rade <jrade1@GWDG.DE>
Subject:      Re: Voluntary method typing in ST80
Comments: To: SMALK%FINHUTC.BITNET@ibm.gwdg.de
              93 1:15 pm

>
>
> I think the whole point of type checking depends on the time at which it
> is performed. In c++ type checking is performed at compile time and is
 required
> since application behaviour when calling with incorrect arguments is
> undefined. Not to mention that the number and type of arguments defines
> which funtion (method) is called. The language and run time environment
> has no mechanism for <Object does not understand>. In fact this cannot
> occur (unless you do some dodgy casting - but what you get then is a nasty
> run time error).
>
> Smalltalk on the other hand does not require (or support in its default
> implementation) type checking. It is up to the application code to check
> the type of arguments.

Good point.
>
> I am curious (see previous posting) about the implementaiton of type checking:
>         1. What if you want to define the same method name, say
>                 process: anObject
>         and
>                 process: anInteger
>         If the type of the argument is used to do checking (presumably at
>         compile time) did you allow overriding of methods ?

Checking is at runtime. Checking at (byte)compile time would at least for
arguments that are passed unchanged from other methods result in pretty
long chains (c.f. the discussion on copying objects).
Do you mean overrinding of parent methods by child methods? Then the answer
is yes.
>
>         2. If a super-class implements
>                 process: anOrderedColleciton,
>         the child class implements
>                 process: anInteger
>         and I call
>                 child process: (OrderedCollection new)
>         what happens, it seems to me that this should allow the super class
>         method to be called.

In the code I posted, the super class method would not be called. I think it
could be done in dialecs, where the Compiler classes are accessible. But
wouldn't this contradict the principle of inheritance?
>
> If the answer to both questions is no, then I wonder about the use of the type
> checking. Sure you would pick up some errors earlier, but not by much. (since
> the method that used the paramaters would fall over pretty quickly too).

I do (partly) agree. I have come across some methods where I named the
argument anInteger, but it was actually aSmallInteger. Although one may
argue that there is nothing wrong with this (and the code could easyly be
extended to handle it), my naming was less precise than it could have
been.
The idea of mechanisms that shape my behavior as a programmer towards
precission strikes me (maybe I need more guidance than other people).
The point I try to make is less on type-cheking, but more on conventions
concerning the naming of arguments: one of the possible sideeffects
would be to have a view on Smalltalk's classes and methods from another
perspective in addition to #sendersOf:/#implementorsOf: and #globalUsers:
(instantiations like: temp := Object new). Although I expect the runtime
for a method that groups methods based on argument types to be long enough
for a coffee break, it could offer another view on class collaboration.
>
> The value of type checking (IMHO) is to ensure that certain classes of errors
> cannot occur. We have a large smalltalk system that has been in production for
> several years now, and it is not rare to see Object does not understand errors
> simply becuase the wrong type of argument has been passed. However I would
> not take on strong typing eagerly since it would destroy much of the
> prototyping
> value that you get in smalltalk.

Right. One can allways reimplement #error: , redirect (some of) the output
into a log file and answer nil.
>
> regards tim

TNX for your feedback - j|g
Newsgroups: comp.lang.smalltalk