[Fwd: Re: .st file naming]

Hi, 


> 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:
> 
> 	ClassName.class/
> 			instance/
> 				fooSelector.st
> 			class/
> 				classSideSelector
> 			meta informationen..
> 
> 	Extension.extension/
> 		..
> 
> 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. 

Jan