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
|