On Sat, 2015-04-04 at 18:12 +0200, Holger Hans Peter Freyther wrote: > On Sat, Apr 04, 2015 at 07:37:36AM +0100, Jan Vrany wrote: > > > I would not go that way. The only reason for this is to track > > method moves. After some 10 years of Smalltalk development, > > I don't think this is so important. > > The other part of it is to be able to more easily export/import > code from Pharo. There is a lot of activity/packages and it would > be nice to support filetree in some form.
Well, you can still have a Cypress reader/writer (which is a format of a (git)filetree - https://github.com/CampSmalltalk/Cypress ) and use it to import/export. In my experience, as of today it's still much simpler just to port monticello and read/save to monticello when one has to work with Pharo/Squeak code. > > > > Second, editing this by hand is a nightmare. After all, GST syntax > > was changed to facilitate hand-editing better, wasn't it? > > ... > > Yes, that would be great! You would need to track classes and > methods (e.g. extensions)? Would we want that inside the Class > and CompiledMethod or have a "registry"? So we could have a > Registry package and VisualGST is loading it first? Yes, each method and package should know its package. In a future, each instvar and annotation too, but we're not yet there (no smalltalk is). I would strongly suggest to keep that within Class and CompiledMethod instances. Doing it otherwise (i.e., registry) is just unnecessary complication because then you must make sure you are always in sync. This is tricky to do, Pharo's RPackage is a an example of it. Another complication would come into the play if you - as you suggested - would like to have it as non-kernel loadable package. Then you somehow would have to initialize the registry so also a kernel methods and all packages that happen to be loaded before are properly packaged. Tricky given that the goal of the "registry" package is to track packages :-) The only reason for having it external in "registry" package I can think of is a memory consideration - no "registry" package loaded, less memory consumed. BUT: for deployment on memory constrained systems you can always drop complete MethodInfo (held by CompiledMethod) to save memory. Similar trick could be done for classes by introducing "ClassInfo" class which would keep package, category, and so on. This way, you save even more memory. Does it make sense? Best, Jan _______________________________________________ help-smalltalk mailing list help-smalltalk@gnu.org https://lists.gnu.org/mailman/listinfo/help-smalltalk
