Squeak-dev Digest, Vol 22, Issue 20

Andreas Raab andreas.raab at gmx.de
Mon Oct 18 04:46:34 UTC 2004


Andres,

> I'm sorry... from my point of view, it was implied because you had
> answered to a matter of "how do you know if a selector is implemented
> by the receiver when the selector exists".
>
> For illustration purposes, how would an optional type system help the
> matter above?  If it's not mandatory, then it's optional, then how is
> it going to be enforced or checked?

First of all, forget "enforcing". There is no enforcement unless you allow 
the type system to affect semantics. And one of the ways that an optional 
type system can help with is by cutting down on the number of possibilities. 
The simplest example for the usefulness of a type system in Squeak would be 
method removal. As it stands, when you remove a method you get a nice 
warning that there are umphteen senders of that message. A type system 
should be able to significantly cut down on the number of senders to look at 
and it could help you by "filing bug reports" with the classes that need to 
be fixed.

> Let's say we go the type inference way.  But if you can prove an
> optional annotation is correct, then why did you type it in the first
> place if you had the answer?...

Personally, I think a combination of the two would be the right thing. Have 
it infer as much as humanly possible but give it a little help if it can't 
really decide. Lex showed me some really interesting examples for this 
(related to infering arithmetic operations).

> Let's say you refactor the code.  It may be necessary to update the
> optional annotations.  The annotations get in the way. What do they buy
> us? What is the problem?

If you start out with the premise that annotations must be getting into your 
way there is absolutely nothing I can do to convince you. Otherwise you'd 
have to give me an example for where you think the annotations would get 
into your way - rarely I've seen the type of a variable change in 
refactoring (most of the time you rename it appropriately). But again, the 
type inferencer would be your friend - it could tell you that "Look there is 
an apparent type conflict here - clearly this cannot be of type Foo (the 
message it sends aren't implemented by Foo) but it looks as if this might be 
a Bar instead. Want me to fix that?". And this could easily be done in the 
background by annotating the class with a little warning which is visible in 
the browser and can be fixed whenever you get around to it.

The more interesting question is "what do they buy us" because that is 
precisely the question about what I'd expect from a type system. And the 
answer is as simple as anything: What I *really* want a type system for, is 
auto-completion. Because that's where the biggest productivity value is - if 
you can type aMorph add<CMD-Q> and instead of the list of hundreds and 
hundreds of completely irrelevant messages get the ones that matter. Other 
than that I think it is nice to be able to have consistency checks and be 
able to see places that need to be fixed right away (and incidentally, unit 
tests might even be used to verify that the proclaimed types match the 
actual ones). And that's about it. There is nothing about code quality, 
there is nothing about speed. It's all about productivity.

And I think the time/effort to do the annotation can be very wisely spent if 
you have a type inferencer to support your work. For example, I'd guess that 
3/4 of Morphic could be handled automatically if just class Morph and its 
methods are typed appropriately. I think you'd get a lot of leverage out of 
very little work.

Cheers,
  - Andreas




More information about the Squeak-dev mailing list