Lukas Renggli wrote:
>> Let's repeat the last part: "while explicitly preserving its meaning or
>> behavior". Not to break things. I'm perfectly cool with that.
> 
> Unfortunately my suggestion is no refactoring from your point of view,
> it breaks backward compatibility.

It's not "from my point of view", but rather "by definition" of what 
refactoring means. I have really come to dislike how the term 
"refactoring" is abused on this list to mean "explicitly breaking code" 
instead of what it means, namely explicitly NOT breaking code.

So, let's be clear: You are not talking about a refactoring. If you 
were, I'd be cool. You are talking about a fundamental and incompatible 
change to the FFI. And I'm not cool with that.

> I am not in favor of keeping backward compatibility, in most cases it
> makes things worse and there are already plenty of bad examples in
> Squeak.

Sure. Depending on the circumstances, e.g., how big your investment in 
Squeak has been and how reliant you are on a specific subsystem, that 
may be a fine option for you. Not all users of Squeak are that way. And 
while I'm not against change in general, I will insist that changes that 
introduce fundamental incompatibilities must be carefully weighed 
against the benefits they bring.

Otherwise, hey, I'm willing to "refactor" Squeak to use proper static 
typing, which will make the code "more extensible", "cleaner" or 
whatever attributes of choice you've been recently using. And all you 
need to do is to rewrite every single method declaration which seems a 
fair deal since you're requesting the same from the FFI users. See what 
I mean? ;-)

> The following presentation of Gilad Bracha might be interesting to
> read, especially the end of the presentation where it says: "Rotting
> Bits for a better World -- A model which expects incompatibility as a
> matter of course is better than denying change."
> 
>     http://www.bracha.org/oopsla05-dls-talk.pdf

As usual, a thought-provoking presentation from Gilad. He is certainly 
right that being prepared for change instead of denying it is the better 
strategy - whether that means to entirely drop having any negotiated 
interfaces however, stands very much to reason. Personally, I find that 
a necessary requirement to be able to deal with change.

Cheers,
   - Andreas