2018-05-14 15:15 GMT+02:00 Marcus Denker <[email protected]>:
> > > On 14 May 2018, at 15:09, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > 2018-05-14 14:44 GMT+02:00 Marcus Denker <[email protected]>: > >> > >> > >> > For ByteArray, I didn't check recently in Pharo, but I know that it's >> quite a mess in Squeak because some methods are in Alien, other in FFI, >> other in base Squeak... >> > IMO all methods should be in core Squeak/Pharo because of general usage >> (like decoding binary data). >> > >> I want to move the methods from FFI to the base since years… I was told >> that this is impossible to ever happen because it is not important to do >> changes like that. >> > > Marcus >> > > Hi Marcus, > we all know that those un-important and not-so-much-rewarding changes > makes a big difference at the end. > like commenting classes, classifying methods, deprecating duplicates, > reducing package inter-dependencies, etc... > I thought that the defenders of statu quo had two reasons in mind: > - the will to keep a FFI-less (locked-in) image > - the fear to loose backward compatibility > > > The idea that “only big important changes” are worth doing… you know, it’s > “inventing the future” business, not “cleaning up”! > > (Of course revolutionary changes while staying 100% backward compatible… > because think about the Children!) > > It would be funny if it would not be sad… > > But's it the past, now you are free :) > > > Not really, because we share that package with Squeak. If I would be free > to change it, it would have happened a loong time ago… > > Marcus > > OK, coordinated changes must be performed then, but it's a bit more difficult... It can be a two step process: 1) separate the methods to be re-integrated in core into a separate package 2) move this methods in core, or use the separate package for old images (backward compatibility) It has to be performed both in FFI and Alien.
