Stef,

To be sure it is possible that my reactions to the arguments are the result
of naivety.  I am not aware of much of the past history and I have not
reviewed the relative parser implementations.  I will back off and let
Andreas and Lukas discuss the details.  

>From my perspective, as limited as it is, there have not been enough
arguments about the benefits of the change itself.  I'm sure the pragma
implantation is quite good based on your judgement but what does that have
to do with FFI.  Using the pragmas implementation for FFI doesn't add or
remove anything from pragmas.  What I can say is that FFI on windows works
well and that the differences suggested for the api are minor but the
compatibility issues are major.  

For me there would have to be a really good reason to want to change the api
for FFI and the arguments I've heard are just not good enough.  IF we could
consolidate the implementation without changing the api I would have no
opinion about this issue accept to point out that FFI as far as I know
belongs currently to Andreas.  

Lukas should aggressively pursue his line of argument so that we can fully
understand the benefits of what he is proposing.  Lukas and Andreas are both
very talented and we would be very foolish not to listen to either of them.


Let's leave politics behind; argument and discussion that leads to a
solution is good for the community and for Squeak.  We don't all have to
agree, we don't need consensus, we need to make sure everyone is heard, make
a decision and then move on.  Like I said the decisions should come from
Andreas and Lukas. 

Ron

> From: stéphane ducasse
> Sent: Wednesday, August 16, 2006 4:53 PM
> Ron
> 
> do not be naive. I asked explicitly to lukas to show his approach to
> get a MUCH cleaner system and we were sure that andreas
> would react that way because we are idiots. So let us be idiots!
> 
> Now I think that taking advantage of pragmas (because you know that
> lukas did all the implementation of pragmas even arguing
> with andreas that he was wrong on certain comments of this
> implementation - this was offline but his happened and lukas was
> right and the implementation of lukas is much better than the one of
> andreas in tweak) would be something to have and discussing how a
> ***smooth transition*** plan could have been prepared. We are not
> saying that everything should change, but preparing to change
> is sometimes really important. Else we would all be programming in
> assembly because it worked.
> 
> But what lukas said is bullshit of course!
> 
> Stef
> 
> 
> On 16 août 06, at 18:18, Ron Teitelbaum wrote:
> 
> > +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
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
> 
>