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 [email protected] https://lists.gnu.org/mailman/listinfo/help-smalltalk
