This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: The Code Grouping Mess
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
Categories, packages, parcels, namespaces, and now annotations. What a confusing mess! This all stems from what appear to be confusing objectives. Packages and parcels have to do with code configuration. Categories and annotations have to do with organizing classes so they can be easily found by programmers. Namespaces are a way to identify, group, and scope shared resources. And just recently, someone (I forget who) provided a goodie for creating a namespace for each package created.
What is being forgotten is the need to create and ship high-quality, independent subsystems. Any competent engineer (in any other engineering discipline) understands the mantra: "To create good systems, create good subsystems." But there is a complete lack of recognition and support for subsystems in Smalltalk (and every other programming language). And that leads to the code grouping mess we now have in Smalltalk.
We never get to a higher level of entity than "groups of objects." Objects are like atoms, but we never get to a higher level than "groups of atoms," that we don't even recognize as being "molecules." We need "cells" and "organs" and other higher level entities (subsystems) in the software hierarchy. Objects, by themselves, are not enough.
The problem we have isn't just one of grouping code and resources for ease of programming and compiling and packaging. We need to step back and ask what is needed to properly support subsystems, and what tools are needed to do that job. This analysis will lead to code groupings that are themselves proper subsystems.
I suppose I am pissing into the wind one more time, but I have applied these concepts to major software projects, and I have seen them applied to a major operating system. They work.
Previous Topic
