> yes, some of this appears to come from a time where 8.3 was
> the rule for filenames.
yeah, I thought so...
> The question is how far we want/can go. In Gemstone/S, Pharo
> there is a push to "filetree". There a class is spread over
> a directory hieracy. E.g. like this:
> meta informationen..
> now this is nice for automatic tools (e.g. move a method
> is a move of a file). Even for "recording changes" it is
> quite nice but the downside is that "git grep" and reading
> a single class at a time is difficult.
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.
Second, editing this by hand is a nightmare. After all, GST syntax
was changed to facilitate hand-editing better, wasn't it?
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 :-)
My experience is that having class per file is OK both for human beings
and for tools. The only thing you need to make sure when doing
from-image "fileout" is to make the method order stable - this makes
auto-merging a lot easier.
> do you have an idea on how to move forward?
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.