On 17 Dec 2009, at 14:15, Stéphane Ducasse wrote: > > On Dec 17, 2009, at 2:27 PM, keith wrote: > >>> >>> You say you are rewriting PackageInfo, you could have rewritten the >>> version that is in MC1.5, and built on what was going before. >>> >> >> For example, do you have support for files in MC? > No > >> do you have support for Package types? > > I have no idea what is a package types. > I have no idea about orphanage. (you see I read the code) > >> do you have Matthew's extra wizzy iteration code? >> >> If you had simply said, we will load LevelPlayingField and fix >> things there, this would have been a different story altogether. >> You insist on making >> things hard for yourself, then you complain that you have no time >> to do things properly. > > But you know like me that MC is central for us and that we did not > want to load code that brings in extra stuff.
What extra stuff? Either MC is to move forward or not. It can only move forward if all users are prepared to move forward. Improvements to MC1.5 effectively ground to a halt when you refused to use it, because the effort of maintaining parity goes up, and the will to move forward goes down. If you had actually used it, you would have noticed the benefits, and improvements of huge refactorings to the repository heirarchy, and the ui tools. We would have had atomic loading debugged by now, and probably binary loading (MC1.7) too. The extra stuff was barely relevant. The orphanage simply keeps anything that fails to load, until such time as it succeeds in loading, thus enabling out of order loading of packages. For example Seaside defines it's own PackageInfo. Package types generalize this such that MyPackage.squeak MyPackage.test MyPackage.impl MyPackage.dolphin pick subclasses of PackageInfo that implement different packaging conventions, that are normally hand coded. Keith _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
