On Wed, 16 Oct 2002, [ISO-8859-1] G�ran Hultgren wrote:
A sidenote: One reason for the Modules work being so... uncoordinated is the lack of a good "CM" tool like CVS or similar. Would you say (I trust your word) that DVS is the best thing going in this respect for Squeak currently? If that is the case, then perhaps we should consider using it for all the Modules-related cooperative work that needs to be done in 3.3. Currently there are a whole slew of .cses floating around that needs to be integrated etc. The lack of something CVS-ish (and I am talking about the very simple update/commit-cycle) is IMHO a big hurdle for real cooperative development in the Squeak image and the Modules area is a good example where we really need this.
Yes, I would say that DVS is the best thing currently going (the only real alternative I know of is CVSTproj, and DVS is much more usable currently). However, DVS is aimed squarely at 3.2 - I have no idea if it makes any sense at all in a 3.3 context, so doing work on the 3.3 modules with it may be a non-starter. You'll have to tell me.
Daniel has already done 5, again in 3.2. I don't see why 6 would be very difficult - it ties into what Daniel and I were talking about with subclasses of Module to store metadata. 6 also seems like something that SqueakMap might be extended to do.
True but I have steered away from that since I didn't want to duplicate efforts
- Modules already has functionality for it.
It would be a pity if people started to "rebuild" stuff (that is already implemented partly in 3.3 Modules) in 3.2 instead of helping out and finishing the job in 3.3...
Well, it not only would be a pity, it *is* a pity, because that's exactly what's happening. I avoided for a long time doing anything that seemed like it was duplicating the 3.3 Modules, but here's the problem: I need this functionality *now*, and I need it to work with all the Squeak tools I currently use. Reimplementing the 10% of the module system I needed in 3.2 was *way* less work than finishing the 3.3 module system + getting all the current 3.2 tools I need updated to work with it. IMO, if a module system is going to get accepted, it's important that a) whatever features it has work, and b) it's backwards compatible. That way people can slowly migrate to it, rather than freaking out because it's currently too broken to work in. Incrementality is the key here. I realize there may be people for whom this isn't true, and so much the better, but for me: there's no chance I can give time to working *on* a version of Squeak that I can't also work *in*.
7 is, of course, the big one: it is the real justification, as far as I'm concerned, of the work that's beem put into 3.3a. But how big a deal is it? Are people routinely struggling with naming conflicts? I tend to throw a 2 letter prefix in front of my class names and forget about it. But maybe that's just me.
I agree but if you have read the Swiki pages about Modules you realize that there are a lot of cool stuff there. The ability to separate loading from activation, working on different versions of classes/modules, clean atomic stages of downloading all dependencies, loading them all into the image and finally activating it all, the global namespace and so on.
Sure, that stuff's all extremely cool. The problem with 3.3 modules is not necessarily technical, but social: I'm beginning to repeat myself, but I'd be much happier with a tiny subset of that *that people actually used*.
Cheers, Avi