Re: .st file naming

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