This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Fragments
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
I spent my CampSmalltalk time working on a project I've called "fragments". You can find it in the OpenRepository as PackageFragments. It was working pretty good under jul03.3 (7.3 alpha), but I've had reports it wasn't working under 7.2(.1). I'll be looking into that shortly. I've fielded a couple of questions about this project, so I thought I'd recap here.
Q: What exactly are fragments? A: Fragments are simply a way of subdividing a Package into separate categories. There was a common pattern used in Envy where when an application got too big, you started using sub applications to "structure" it. The analog to this in Store seems to be to create a bundle and then use packages as incomplete sub parts. The problem with this is--for me--it makes it hard to write automation tools when you have no way of inferring what the package authors structuring intent was. I thought it would be better to provide a mechanism to subdivide existing packages that had grown large, rather than to force people to change the interpretation of what a package was.
Q: Why do you call them fragments? What's wrong with categories? A: Nothings wrong with the word categories I guess. I called them fragments for a couple of different reasons. I was going for an original name. Class categories have been on the out for a while now, I wanted to distance myself from the opinions and implementation. Finally, it embodied the intent in the first place. To me, the work package denotes a certain amount of closure and completeness. When I browse/load something called a "package", I expect it to be a self contained component. A structural sub part of a package is not a whole closed piece. One might say, that you could break a package up into fragments. Again, to me, the word "fragment" denotes the opposite, just a sub part, not capable of representing the whole (Here's an interesting counter question. Why are classes traditionaly "categorized" but methods are "protocoled". Why don't we have method categories? Why don't we have class protocols?).
Q: Couldn't you just use Categories, and then display those in the browser? A: You could. In fact John Brant sat down and did a nominal version that did just that in about an hour. I had three reasons for not doing so
I wanted to control the model. With class categories being factored out of the system, I didn't want to have to keep up with those changes. And I didn't want to be constrained by what class categories could and couldn't do. Using an original model, meant I could evolve them whereever need be.
I wanted the fragment names to be relative to the Package, not the system. In other words, if you put a Class definition in Fragment YourPackage>>YourFragment, and then I extend your class, I want to be able to put your class in a Fragment name that is relative to the extending package, not be forced to use whatever category you stuck your class in.
It seemed inconsistent to organize classes in packages via menu picks and drag/drop, but than organize then in fragments (sub pacakges) by editing class definition template.
Q: Does this mean that packages that are "fragmented" require PackageFragments? A: No. That was one of the goals. The package fragment information is stored as simple data in the properties of the package. The Fragment objects are transitory and simply put a package like interface on top of this information. What this means, is that you can fragment a package, and someone can load and use your package without having the PackageFragments tool loaded. It's meant to be totally passive.
Q: Any chance of this being integrated? A: My understanding is that Vassili Bykov is supportive of the idea (he's the chief VisualWorks tool guy). His and my constraints in developing/maintaining/integrating such a beast are entirely different. So, I would expect that if this implementation proves to be promising in what it achieves, then a clean version, where some of the constraints listed below would be lifted, could be integrated.
Q: Are you proud of this code? A: I'm proud of what it accomplishes. Looking at the implementation, I'm pretty ashamed. It's hack after hack. Which pretty much ensures a long life probably. There were some interesting constraints in developing this. For one, it was very much incremental design by discovery. I don't have a big picture mental model of the mechanics of both the RB and Store. So feature, by feature, I explored what needed to change and made the simplest change. Understanding it a little better now, it wouldn't hurt to sit back and design a more solid model. I was constrained by the fact that I'm not one of the core VW developers. To make any progress with this, I have to leave patches/changes to the base system pretty minimal. Furthermore, there's the constraint (listed above) that the presence of Fragment data be entirely passive and backwards compatible.
Previous Topic
