Re: Grace and Maps (was Re: Development process in the Ada community)

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

"Brian Gaffney" <Brian.Gaffney@myrealbox.com> wrote in message
news:5e9b8c34.0204241829.67633bdf@posting.google.com...
>
> If I get your intent, I don't think this would work since Grace.List
> would be generic.  (Which would be a pain if you needed Bounded
> because you didn't wish to instantiate an Unbounded.)
>
O.K. So maybe we just need Grace.Lists and Grace.Bounded_Lists? Probably,
90% of the uses will just want a dynamically allocated, linked list
implementation as being Good Enough(tm). Hence, it can benefit from the
shorter name. Lesser demand packages can have longer names either by
dotted-child notation or just more detailed names.

Or we could just invent new names to describe data structures with different
characteristics as I suggested somewhat less seriously elsewhere. You could
have Grace.Lists, Grace.BLists, Grace.Whatever.... So long as it is
documented what the characteristics of a BList are, we don't have a problem.
Or completely make up new names that don't play to anyone's preconceived
notions of what they are.Grace.Rosters? Grace.Rolls? Grace.Catalogs? There
you've got three more names to describe lists with different caracteristics.


>
> I like the Grace.Containers.Lists idea.  Perhaps the children could be
> something like Grace.Containers.Bounded.Lists?  Then you could have a
> Grace.Containers.Maps and Grace.Containers.Bounded.Maps, etc.  I don't
> know how well this would extend to other types of containers.
>
We've got to be *real* careful not to make a naming scheme that tries to
have so many branches to such a depth that everyone will later decide that
it is a Royal Pain In The Posterior to use it. If we start creating subtrees
to describe implementation strategies and characteristics, where does it
end? Grace.Containers.Bounded.Task_Safe.Realtime.Deterministic.Maps? :-) We
can't solve *all* the problems today. A Grace.Containers.Lists and
Grace.Containers.Maps is probably sufficient granularity for now and a
sub-branch could be created later if there is any real need. (Some flavor of
Grace.Bounded_Containers? Although I'd favor shorter names for these things.
Like Grace.Boxes or Grace.Jars - or even an acronym.)


> Another way to get a default (assuming anyone could stand it) would be
> to provide the different version (unbounded, bounded, etc.) and uses a
> renames to define the 'default' type (i.e. generic package
> Grace.Containers.Lists renames Grace.Containers.Unbounded.Lists).

Apply the K.I.S.S. principle here. One of the design criteria was that it be
relatively easy to explain to students - and that was one of the reasons
people had objections to the Booch Components. Too many layers and too much
complexity for the average beginner to make good use of it. Providing a
default renaming of some alternate implementations might not be a bad way to
go, but I'm wondering if it would create too much confusion? Would it be
easy to explain to a beginner?

I think that so long as the tree structure is extensible without too much
pain, it will be satisfactory. One day, we might want a bunch of packages
with the power of the Booch Components & I could see building it under a
heading Grace.Rich_Containers (or whatever) but we need to continue to have
something reasonably simple and straightforward to handle a large percentage
of the needs without too much pain.

MDC


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