Re: [Help-smalltalk] .st file naming

[Jan Vrany]

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