Re: "static" declaration

[Daniel Weinreb <address@hidden>]

Sorry to be so late to reply to this.

Lieven Marchand wrote:

>Dan Weinreb <dlw@smartleaf.com> writes:
>
>>When Moon was doing New Flavors, I lobbied him very hard to put in an
>>explicit concept of "interface", and he stolidly resisted.  Moon is
>>very rarely wrong about anything, but in this case I still think he
>>was wrong.  When Java came out, many years later, with a genuine
>>"interrace" feature that was pretty much what I'd always wnated, I was
>>very impressed.
>>
>
>Did you have a specific idea in mind for this interface concept in New
>Flavors? 
>
I didn't have a well-developed proposal, no.  It was clear that Moon 
wasn't interested so
I didn't take the idea that far.

>I still don't see what it would buy. In Java, the compiler
>will complain if you haven't implemented every method of an interface
>you claim to support. This is something CL won't do unless you try to
>call that method. This is the same trade off made in other parts of
>the language wrt static/dynamic typing. 
>
Yes, that's true.

>The counterproblem in Java is
>that a published interface can't be extended without breaking previous
>clients. 
>

Indeed.  We saw some really good stuff at LL1, both from the Smalltalk 
and the Javascript
world, about how to deal with these issues, and I'm sure Java could 
benefit from that stuff.

>In Java, it's also impossible to supply default
>implementations of methods in an interface, which I find really
>clumsy.
>

Well, I know what you mean, and in a sense it is clumsy, but in another 
sense it is the
Right Thing.  Interfaces are not about implementation, and really ought 
to completely
keep their paws off the question of how anything is implemented.

After all, there might be more than one implementation strategy for a 
shared abstract
base class for a given interface.  Suppose the interface is 
output-stream.  You might
have one abstract base class called char-output-stream that says "if you 
want to build
an output stream, you should provide an output-this-character method, 
and then build
yourself on top of me and I will supply the other useful methods like 
output-this-string".
Then there could be a second, distinct abstract base class called 
string-output-stream
that says "if you want to build an output stream, you should provide an 
output-this-string
method, and then build yourself on top of me and I'll provide the other 
useful methods
like output-this-character".