+1 

The arguments presented are not sufficient in my opinion to warrant the
change.  

In general the amount of difference in the interface that is suggested is
trivial when compared to the amount of learning necessary to use FFI.
Consistency does not appear to me to be a valid argument.

Considering the alternatives presented by Andreas that allows this minor
difference in syntax while satisfying requirements for isolation, I would
say it's better to leave current systems working and the current syntax as
is even if it is slightly different than pragmas.  Isolation of code and
removing of unnecessary code when FFI is unloaded does not appear to be a
valid argument considering alternatives discussed. 

I understand the original stated goal is to unify the parser and clean up
the parsing code, but in general that doesn't seem to be enough of an
argument to change the interface of working systems.  Can the two parsers be
combined without changing the FFI syntax?  

Ron Teitelbaum

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Andreas Raab
> Sent: Wednesday, August 16, 2006 11:36 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Proposal for Extensible Primitives (was: FFI)
> 
> 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
> >>
> >
> >
> >
>