Proposal for Extensible Primitives (was: FFI)

> I propose the following changes:
>
> Problem: FFI is hardcoded into the Squeak parser and uses a special
> parsing method. While parsing pragmas the implementation has to check
> for special conditions (Parser>>pragmaStatement) to trigger special
> handling of FFI functions (Parser>>externalFunctionDeclaration). This
> adds unnecessary code requirements to the base image and violates the
> extensibility of the system.
>
> Current State: Squeak primitives in 3.9 are already parsed using the
> pragma parser, they fully comply the new syntax. As a post operation
> the parser checks for these primitive pragmas and modifies the
> compiled method to call the primitive instead of the fallback code.
> FFI primitives have a slightly different syntax than the pragmas
> therefor are handled differently.
>
> Solution: Unify parsing of pragmas and FFI primitives. Make the
> primitive parsing extensible using pragmas.
>
> Proceeding: As a first step I would remove all the hardcoded code to
> parse Squeak and FFI primitives. Then I would tag the already
> implemented methods #primitive: and #primitive:module: using the newly
> introduced pragma #primitive, so that the parser is able to
> automatically detect these methods and postprocess the compiled method
> after the parsing.
>
> Proceeding FFI: The FFI package would add two extension methods to the
> parser, in the example below these would be #cdecel:module: and
> #apicall:module:. The implementation would look similar as the current
> implementation in #externalFunctionDeclaration, the parsing however
> (except for the C declaration) would have been done by the pragma
> parser already. The syntax of FFI primitives would need to be changed
> from
>
>     XSetBackground: xDisplay with: xGC with: bg
>         <cdecl: void 'XSetBackground' (X11Display* X11GC long) module:
> 'X11'>
>         ^self externalCallFailed
>
> to something like
>
>     XSetBackground: xDisplay with: xGC with: bg
>         <cdecl: 'void XSetBackground(X11Display* X11GC long)' module:
> 'X11'>
>         ^self externalCallFailed
>
> As a free goodie, we could now look for all FFI calls by simply
> looking at the senders of #cdecel:module: and #apicall:module:.
>
> I can do the proposed changes. We can also discuss about the
> implementation, though I won't go into any discussion if pragmas are
> good or evil ;-)
>
> Cheers,
> Lukas
>

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Andreas Raab
> Sent: Monday, August 14, 2006 8:04 PM
> To: The general-purpose Squeak developers list
> Subject: Re: Proposal for Extensible Primitives (was: FFI)
>
> Hi Lukas -
>
> What problem exactly are you trying to solve? The way I understand it
> the problem we have is a dependency problem - how can the FFI cleanly
> interact with the parser. To do this, I would simply add a class
> variable that points to some FFI support class handling the parsing
> requests. If the FFI is loaded it registers the appropriate entry point
> and it unregisters it when unloading. As far as I can see, no further
> changes are needed, in particular none that break compatibility.
>
> Cheers,
>    - Andreas
>
> Lukas Renggli wrote:
> > I propose the following changes:
> >
> > Problem: FFI is hardcoded into the Squeak parser and uses a special
> > parsing method. While parsing pragmas the implementation has to check
> > for special conditions (Parser>>pragmaStatement) to trigger special
> > handling of FFI functions (Parser>>externalFunctionDeclaration). This
> > adds unnecessary code requirements to the base image and violates the
> > extensibility of the system.
> >
> > Current State: Squeak primitives in 3.9 are already parsed using the
> > pragma parser, they fully comply the new syntax. As a post operation
> > the parser checks for these primitive pragmas and modifies the
> > compiled method to call the primitive instead of the fallback code.
> > FFI primitives have a slightly different syntax than the pragmas
> > therefor are handled differently.
> >
> > Solution: Unify parsing of pragmas and FFI primitives. Make the
> > primitive parsing extensible using pragmas.
> >
> > Proceeding: As a first step I would remove all the hardcoded code to
> > parse Squeak and FFI primitives. Then I would tag the already
> > implemented methods #primitive: and #primitive:module: using the newly
> > introduced pragma #primitive, so that the parser is able to
> > automatically detect these methods and postprocess the compiled method
> > after the parsing.
> >
> > Proceeding FFI: The FFI package would add two extension methods to the
> > parser, in the example below these would be #cdecel:module: and
> > #apicall:module:. The implementation would look similar as the current
> > implementation in #externalFunctionDeclaration, the parsing however
> > (except for the C declaration) would have been done by the pragma
> > parser already. The syntax of FFI primitives would need to be changed
> > from
> >
> >     XSetBackground: xDisplay with: xGC with: bg
> >         <cdecl: void 'XSetBackground' (X11Display* X11GC long) module:
> > 'X11'>
> >         ^self externalCallFailed
> >
> > to something like
> >
> >     XSetBackground: xDisplay with: xGC with: bg
> >         <cdecl: 'void XSetBackground(X11Display* X11GC long)' module:
> > 'X11'>
> >         ^self externalCallFailed
> >
> > As a free goodie, we could now look for all FFI calls by simply
> > looking at the senders of #cdecel:module: and #apicall:module:.
> >
> > I can do the proposed changes. We can also discuss about the
> > implementation, though I won't go into any discussion if pragmas are
> > good or evil ;-)
> >
> > Cheers,
> > Lukas
> >
>

> Hi Lukas -
>
> What problem exactly are you trying to solve? The way I understand  
> it the problem we have is a dependency problem - how can the FFI  
> cleanly interact with the parser. To do this, I would simply add a  
> class variable that points to some FFI support class handling the  
> parsing requests. If the FFI is loaded it registers the appropriate  
> entry point and it unregisters it when unloading. As far as I can  
> see, no further changes are needed, in particular none that break  
> compatibility.
>
> Cheers,
>   - Andreas
>
> Lukas Renggli wrote:
>> I propose the following changes:
>> Problem: FFI is hardcoded into the Squeak parser and uses a special
>> parsing method. While parsing pragmas the implementation has to check
>> for special conditions (Parser>>pragmaStatement) to trigger special
>> handling of FFI functions (Parser>>externalFunctionDeclaration). This
>> adds unnecessary code requirements to the base image and violates the
>> extensibility of the system.
>> Current State: Squeak primitives in 3.9 are already parsed using the
>> pragma parser, they fully comply the new syntax. As a post operation
>> the parser checks for these primitive pragmas and modifies the
>> compiled method to call the primitive instead of the fallback code.
>> FFI primitives have a slightly different syntax than the pragmas
>> therefor are handled differently.
>> Solution: Unify parsing of pragmas and FFI primitives. Make the
>> primitive parsing extensible using pragmas.
>> Proceeding: As a first step I would remove all the hardcoded code to
>> parse Squeak and FFI primitives. Then I would tag the already
>> implemented methods #primitive: and #primitive:module: using the  
>> newly
>> introduced pragma #primitive, so that the parser is able to
>> automatically detect these methods and postprocess the compiled  
>> method
>> after the parsing.
>> Proceeding FFI: The FFI package would add two extension methods to  
>> the
>> parser, in the example below these would be #cdecel:module: and
>> #apicall:module:. The implementation would look similar as the  
>> current
>> implementation in #externalFunctionDeclaration, the parsing however
>> (except for the C declaration) would have been done by the pragma
>> parser already. The syntax of FFI primitives would need to be changed
>> from
>>     XSetBackground: xDisplay with: xGC with: bg
>>         <cdecl: void 'XSetBackground' (X11Display* X11GC long)  
>> module: 'X11'>
>>         ^self externalCallFailed
>> to something like
>>     XSetBackground: xDisplay with: xGC with: bg
>>         <cdecl: 'void XSetBackground(X11Display* X11GC long)'  
>> module: 'X11'>
>>         ^self externalCallFailed
>> As a free goodie, we could now look for all FFI calls by simply
>> looking at the senders of #cdecel:module: and #apicall:module:.
>> I can do the proposed changes. We can also discuss about the
>> implementation, though I won't go into any discussion if pragmas are
>> good or evil ;-)
>> Cheers,
>> Lukas
>
>

> Primitives would have a consistent syntax and would work searchable
> such as senders and implementors of a method. Moreover no code would
> be left over in the compiler package, namely the function
> Parser>>#externalFunctionDeclaration could be part of the FFI package.
>
> Of course I am wasting my time with minor details ;-)
>
> Cheers,
> Lukas
>

> 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
>

>
> 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
>>
>
>
>

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] 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
> >>
> >
> >
> >
>

> +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: [hidden email] [mailto:squeak-
>> dev-
>> [hidden email]] 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
>>>>
>>>
>>>
>>>
>>
>
>
>
>

> 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: [hidden email] [mailto:squeak-
> >> dev-
> >> [hidden email]] 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
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
>
>