stéphane ducasse wrote:
> would not be possible to have a plan for a smooth transition even with 
> the two approaches happily living side by side?

A transition implies that the proposed change is desirable or necessary. 
This is not the case. The idea to change the syntax of the FFI is a 
classic "fresh from the ivory tower" idea, neglecting the realities of 
an already deployed, perfectly working and functioning system.

Sorry but changing FFI syntax ain't gonna happen on my watch.

Cheers,
  - Andreas

> 
> Stef
> 
> On 16 août 06, at 09:41, Andreas Raab wrote:
> 
>> 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
>>
> 
> 
>