Re: Containers with Ada

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Stephen Leake wrote:

> Brian Rogoff <bpr@shell5.ba.best.com> writes:
>
> > <snip>
> >
> > Rather than telling other people what you'd rather they do, why
> > don't you just go do it yourself? If someone wants to create another
> > container library in Ada I say "more power to'em!". That ground
> > doesn't look old and tired to me.
>
> Someone looking to create an Ada library should make an attempt to
> find out what's already been done. Then they can either just use it,
> or improve on it, or start from scratch. In any case, we'll all learn
> something (if they tell us :).

There are other factors that must be considered before using an
EXISTING package:

  1. -  Who controls its design and interface?
  2. -  Is it likely to undergo changes in the future?
  3. -  How stable are the various existing releases of this package out there?

If I write an application for donation to the Open Source movement,
these are often deciding factors for me. For example, if I write an
application based upon the florist package, and the package specs
change, then people who try to compile my application are going to
whine to me that it doesn't compile. (Actually, the specs need not change--
for example there can be unresolved links in the library etc. leading to
other build problems).

Many users out there that barely can manage a make command, don't
recognize where the problem lies. Consequently, if I suspect that this
will be a problem, I'll create my own interfaces that are NOT subject
to change (or implementation problems).

Even if issues 1 and 2 are resolved, #3 can be a problem. For example
if there are many distributions out there with busted florist libraries installed,
then I have to either:

   a)  include comprehensive instructions to the user to identify and upgrade
        the offending packages/libraries..
   b)  or insulate my application from these problems, to avoid whining
        emails.

Often, I'll choose "b" because my time is too short to help all the users work
out issue "a".

CONCLUSION:

Consequently, only if a package and most of it's existing versions are stable
and working, will I consider it for an open source project. For internal projects,
this is not really an issue (I can just grumble when it needs adjustment, but then
I only need to fix it once -- not for every other user out there).

> --
> -- Stephe

POSTSCRIPT:

This is the reason I think it is VERY IMPORTANT that standards be developed
for re-usable components. Once the standard is announced, the developer has
some sort of assurance about the interfaces involved, today, and into the future.

Warren W. Gay VE3WWG
http://members.home.net/ve3wwg