Re: .st file naming

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.


> Second, editing this by hand is a nightmare. After all, GST syntax 
> was changed to facilitate hand-editing better, wasn't it? 

It was before my time but yes, the current syntax is certainly
more fun than fileout :)

> Third, this would be nightmare to implement in a VM as the VM
> currently loads and compiles .st files when assembling a kernel
> and loading packages. There will be a need for a JSON parser, too. 
> (I'd like to nuke the whole parsing and compilation logic out of the
> VM, but let's leave this for later :-) 

Good points too.


> Yes :-) One can write a code that file outs a package (treating kernel
> as package like any other) and just read into the image and then spit
> out new files. 
> One problem is that - AFAIK - there's no way to figure out to which
> "package" given code element belongs. So first step would be to add
> a reflection API for that. 
> The idea is to keep reference to package object in each class and
> in method info. 

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?