On Tue, Apr 07, 2015 at 08:35:44AM +0100, Jan Vrany wrote: > 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.
Yes, I started twice with porting Monticello and didn't complete it. Did you get further? Did you start with Pharo or the Gemstone/S version? What do you do with traits and other items we don't support yet? How to resolve a conflict when loading? > 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 :-) I would have simply marked everything as "kernel" that is loaded before the registry package. The benefit of a registry is that depending on your storage structure you don't need to walk all classes/compiled methods to find the ones that belong to a package. > 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? yes, it does counter my argument of just having an "external" registry. Let's see if Paolo comments on "ClassInfo". holger _______________________________________________ help-smalltalk mailing list help-smalltalk@gnu.org https://lists.gnu.org/mailman/listinfo/help-smalltalk