comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Booch Components question
Date: Mon, 14 Nov 2011 17:18:14 -0600
Date: 2011-11-14T17:18:14-06:00	[thread overview]
Message-ID: <j9s7jn$m45$1@munin.nbi.dk> (raw)
In-Reply-To: m28vnlb9ry.fsf@pushface.org

"Simon Wright" <simon@pushface.org> wrote in message 
news:m28vnlb9ry.fsf@pushface.org...
...
> If anyone has objections/suggestions, now would be a good time to raise
> them; thanks in advance.

[I don't use your components and haven't looked at them in many years, but I 
can't resist commenting. Feel free to give this comment the value you think 
it deserves... :-)]

I'm of two minds of this (maybe even more).

First, if someone needs *simple* components, they are best served by using 
the Standard ones added in Ada 2005. Even if they have to use Ada 95, they 
can use the Ada 2005 components with a few small modifications (change the 
name to Ada_Containers, and replace the anonyomous access types with named 
ones). [Ada 95 use of the containers will limit instantiations and 
call-backs to library-level, annoying sometimes but not a major hardship.] 
Using these containers means that they will be available on (most) future 
compilers and presumably will decrease the learning curve for future 
maintainers (most Ada programmers will be at least somewhat familar with 
them).

So, for alternative components to be valuable, they need facilities beyond 
the basic ones supported by Ada 2005 and even Ada 2012. This funny "list" 
container seems to be in that category. So it would seem to be a shame to 
lose it.

OTOH, the name "list" seems highly confusing. "List" seems to have gained a 
fairly standard meaning in the use of containers, and I'm not surprised that 
most people look there first. Having something that works rather differently 
with that name is asking for trouble.

So my suggestion would be to rename the container to something else to 
reduce the confusion. I realize that would add some confusion vis-a-vis your 
original source material (and a compatibility problem easily solved with 
package renames), but I expect the net effect would be much better.

OT3H :-), if people move to the Standard containers as we would hope, it 
doesn't really pay to maintain alternatives at all. So it might make sense 
to just deep-freeze the thing (don't waste time on enhancements or bugs 
unless awful), but keep it around for interested parties.

                                    Randy.







  reply	other threads:[~2011-11-14 23:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-12 16:11 Booch Components question Simon Wright
2011-11-14 23:18 ` Randy Brukardt [this message]
2011-11-15  9:00   ` Dmitry A. Kazakov
2011-11-15  9:23     ` Simon Wright
2011-11-15 10:08       ` Dmitry A. Kazakov
2011-11-15 10:06   ` Simon Wright
2011-11-15 11:19     ` Simon Wright
2011-11-15 23:26       ` Jeffrey Carter
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox