This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: BaseExtensions -- and a proposal
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
Do you have one of these at your company? A package where you put methods, which extend the base system, methods that you feel are kind of useful to many of your applications? Or is that just me? Every company I've worked at has one. But maybe that's because I always create them. I hear people talking about this or that handy method on OrderedCollection often though, so I'm going to assume that I'm not alone in this practice.
There's a couple of drawbacks that I see from this practice though:
Redundant Efforts -- All of the "add to the base" practitioneers have lots of redundancy in their efforts. Lots or people have implemented Stream>>nextLine. Or Collection>>anyOne. It's a mass case of wheel reinvention. Of course, we all like to name them slightly be different, but that's trivial.
No Collaboration -- When VW7.0 was rolling out, there was a flurry of additions to the base that got nominated. I think it was Eliot Miiranda that solicited it and I thank him for doing so, and including many of the nominations. I had a couple of that were include--I hope others have benefited from them. But what I'm really grateful for is the holes that some of the other nominations filled for me. I use fold: and gather: lots. And many others.
Overweighted Dependents -- You decide you want to make one of your packages a little more modular, put it up on the Open Repository. You've used 1 or 2 of your extensions to the Collection heirarchy, but you can't really publish and prereq your BaseExtensions package! It's too big. It drags in stuff for Filenames, Streams, Numbers, etc. And because of the Redundant Efforts issue, you may collide with someone else's code. So you end up not using the handy extensions, and then... what was the point of having the extensions in the first place?
Dumping Grounds -- Having such a package often leads to developers writing such-n-such an extension and coming to the conclusion, "hey this is really handy--aren't I smart to have thought of this--other people will want this" and tossing their extensions in there. Four years later, you're reviewing your extensions package and you're asking "ok, who uses Collection>>withoutEveryNthElement: aFrequency??" and of course it's still just the one project. The truly reusable stuff is lost in the noise.
So here's my proposal. Why not do a collaborative style open source project for something like this? My thinking is, one of the subsystems of the system is chosen (good start for subsystem categories might the be the 10 or so which ANSI defines). I'd like to nominate Strings. A package is created in the Open Repository. ExtraStrings sounds good to me (grin). I could be swayed to something like StringSystemExtensions too. An empty version 0 is published. And then people can begin adding their methods to it. We use some versioning scheme whereby the linear version numbers are numbered 0, 1, 2, 3. To nominate additions you publish on a branch. And we use some convention with the branches to find concensus among the nominations. So that anything in the trunk is approved by mutliple people. We try it out--sort of an experiment--and see how it goes. If it goes well, we do the same for other subsystems. I see such a thing as being a positive improvement on all 4 of the drawbacks listed above. Reactions?
Previous Topic
