Hi list,

Andreas and Lukas, sorry to put words in your mouth once again, but that's my understanding:

Lukas: make framework simpler, more uniform, and more easily maintanable in the future.
This is a maintainer of Compiler and pragmas point of view.

Andreas: protect investment and avoid frequent swaps when no value added.
This is the FFI user (and maintainer) point of view.

Both arguments seems receivable to me.

Simplifying implementation is something worth because without it, Squeak will evolve slower and slower, and future maintainers who don't know the whole history won't understand the complexity and will probably break things sooner or later.

The alternative proposed by Alejandro is to fork.... Easy solution for maintainers ! But painfull for users who want to gather features from several forked branches ! As long as possible, please don't fork (or only temporarily).

My feeling is that the Compiler maintainers should decide whether or not the implementation should change, but in this case, it is also their responsibility to provide a backward compatibility for FFI users.

Optional backward compatibility package can take two forms in this case:
1) simply allow older syntax in the compiler (and/or NewCompiler ?)
2) automagically transform older syntax into newer form when loading code

The second one would have my preference since it would ease the syntax transition.
Of course, it would be the job of various FFI client package maintainers to simply add the backward compatibility package to prerequisite list.

Couldn't we follow such procedures when making the code evolve in uncompatible manner ?

Nicolas


________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com