Re: [Help-smalltalk] .st file naming

[Jan Vrany]

> 
> > 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. 

But then the package to which certain code element belongs would 
depend on in which order you load packages. Very bad IMO. 
Alternatively, you may have it as prerequisite of every package, 
but that's bit silly :-) 

> 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.
> 
True. But how often one need to do that? When you commit or when
one want to display code that belongs to a package. Both are not
performance-critical operations and walking through all classes is
fast enough. 

Anyway, having this feature in kernel or in external package is 
orthogonal to external data structure or reference from class(info) and 
method(info)

There's one more complication to keep in mind, independent of above. 
overwrites have to be handled too. A method has to keep the overwritten
method. Again, one can keep it in MethodInfo...

> 
> 
> > 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".
> 
Yes. Paolo? 

Jan