Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

I looked over the Booch Components several years ago and have not revisited
them since. Perhaps they have evolved some since then so my comments may not
be appropriate.

One big weakness I found in them was a general lack of documentation. If
*any* set of data-structury-ADT-ish stuff is to be adopted as a de-facto
standard (presumably, tacked on with compiler distributions, etc.) it would
need some documentation that explains the behavior and proper use of the
classes/packages. You can't dump a library on a newbie and say "Here: Read
the code and figure it out for yourself..." It need not be a textbook, but
some minimal level of a user's manual needs to be there.

Demo/Test programs - it had some when I looked it over. I thought they could
stand to be a little more thorough and possibly illustrative of proper
usage - build a document that hyperlinks to example & test code?

It ought to be noted that something like the Booch components are not going
to be suitable for all applications. If they rely on dynamic memory, they
may be unsuitable for any sort of realtime work. If they rely on fixed
memory, they may not be suitable for very dynamic workstation apps. If they
provide both implementations, they may be "too big" and/or offer too many
choices to the user. IOW, they cannot be all things to all users and hence
it should be clear as to what the intended usage is.

One thing that may be important is to consider how they might be extended to
include new features should the need become apparent. Could this serve as
the basis for a more general library of components rather than just a
data-structure library? (Bundle into it things like an OS interface, network
support, math libraries, etc.?)

Also, one of the things I found very useful in the MFC was the ability to
"serialize" an object. The same thing is possible in Ada95 with streams. It
would be A Good Thing if the Booch components provided Load/Store operations
from/to a Stream file.

Licensing is another issue. Some people love the GPL, but others may not
want to contaminate their code with that. What license is the Booch
Components currently under and does it allow unfettered use in everything
from "Open Source" (whatever that means currently) to totally proprietary -
maybe even classified - applications?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:Bggx7.314$KN5.148429887@newssvr11.news.prodigy.com...
> "Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
> news:9pvv3t$ves$1@news.huji.ac.il...
>
> <snip>
>
> > I think that adding Collections to the standard library would be a big
> help.
> > I find it sad that when I want to explain what Collections are, I print
> > stuff from the Java docs ;-(
>
> This is an issue that has troubled me for some time.
>
> Many of us have developed libraries of reusable components over the years.
> It is a great way to learn a language.  We all have things we like about
> them.  Some are extensive and well done.  However, we would all clearly
> benefit by agreeing to make one of them the de facto standard.  (Formal
> standardization is desirable too, IMHO.)
>
> I propose the Booch Components be that standard.  If there is a better
suite
> I haven't seen it and I've seen many of them.  However, there may very
well
> be a better collection of components.  Let's discuss them.
>
> Whatever we choose, an incomplete list of steps required include:
>
>     Start using them instead of our individual in-house favorites.  That's
> the hard part.
>
>     Have a community-wide decision to adopt them, so that the above can
> happen.  Unless a significant number of people publicly agree to adopt
them
> there will be few individuals willing to make the change.
>
>
> Thoughts?
>
> ---
> Patrick Rogers                       Consulting and Training in:
> http://www.classwide.com          Real-Time/OO Languages
> progers@classwide.com               Hard Deadline Schedulability Analysis
> (281)648-3165                                 Software Fault Tolerance
>
>