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? _______________________________________________ help-smalltalk mailing list help-smalltalk@gnu.org https://lists.gnu.org/mailman/listinfo/help-smalltalk
