[Fwd: Re: .st file naming]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[Fwd: Re: .st file naming]

Jan Vrany

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



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk