[squeak-dev] Did we really nailed files?

Casey Ransberger casey.obrien.r at gmail.com
Thu Apr 7 23:55:28 UTC 2011


IMHO fake packages are awful. 

There's no actual modularity going on with them, which is confusing to new people who've had modules in every other language that were namespaces. 

All I get out of PackageInfo is having to make two commits instead of one when I modify behavior that reaches across "packages" and hope that trunk isn't broken for anyone who happens to click update before my second commit. 

I like the naming convention for extensions, actually. OTOH I *hate* the overrides. I don't care how convenient it is, it fuels Balkanization because it makes porting apps painful. 

PackageInfo := Bag mixed. 

Note that while I'm criticizing MC & PackageInfo here, I will quite confidently say that the new community development model has been a huge success: Squeak development is now unclogged. So MC is working, I just don't think it's ideal. 

On Apr 7, 2011, at 4:23 PM, Chris Muller <asqueaker at gmail.com> wrote:

> I'm with you on the filtering.  But a lot of that could be solved at a
> tool-level.
> 
> I think a Package is a essential unit of organization; semantically
> and practically.  I agree it would be nice for inter-package
> operations, as well as refactoring operations, to be able to be better
> integrated.
> 
> I also agree that file-based SCM does introduce challenges and a lot
> of redundancy.
> 
> But MC1 is impressive by its staying power and relative simplicity.
> 
> - Chris
> 
> 
> On Thu, Apr 7, 2011 at 5:35 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> File based SCM are a nightmare. Did you ever tried to re-organize
>> source files into a different directory structure, or even worse
>> reorganize classes/functions in files ?
>> Fortunately Parc nailed files from Smalltalk for us a while ago, didn't they?
>> 
>> Files, yes, but the idea of directory/folders is sticky.
>> One avatar is the package, at least as it is defined now in
>> Squeak/Pharo/VW: an arbitrary boundary for organizing class and
>> methods with no semantic. Smell a lot like file/directories, doesn't
>> it?
>> 
>> The bad news is that our tools for handling those blobs are as bad as
>> the others from this POV.
>> If you move a class/method to a different package, you ain't gonna
>> track it/diff it/merge it that easily with MC1...
>> And this is a concrete problem when you wanna merge some Squeak/Pharo
>> changes for example.
>> VW Store suffers from same Achille heel AFAIK.
>> Not only is it unpracticle, it was (is?) bugged (especially if you
>> have silly ideas like playing with overrides)...
>> Just browse the numbers of ARs related to interpackage motions if you
>> have access to such database .
>> 
>> At the end I find myself still using rough filed out change sets...
>> Just the leafs of the arbitrary organizational tree, but that's enough
>> they carry all the semantic.
>> A pity (but thanks they are still there).
>> Barely enough are the filtering tools (especially in Squeak/Pharo -
>> Even MC UI seriously lack filtering facilities, a must-have for cherry
>> picking).
>> Should I have a look to MC2?
>> 
>> Nicolas
>> 
>> 
> 



More information about the Squeak-dev mailing list