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

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

"Ted Dennison" <dennison@telepath.com> wrote in message
news:3CC1C6B3.6060306@telepath.com...
>
> I honestly have no clue. The vast majority of my Ada use has been
> real-time or embedded (where dynamic allocation is often unavailable),
> and I do notice that there seem to be a large number of Ada compilers
> for such platforms. But I also realise that's just the view from my
> window, not a scientific representative sample.
>
To be fair, I have to admit similar ignorance. All I can go on is a general
perception that most programs written are not realtime/embedded so
extrapolate from there and presume that most Ada programs are not
realtime/embedded. You've got to ask "who's the audience?" and starting from
an unproven assumption and using a weak extrapolation, I'm willing to leap
to the forgone conclusion that we ought to target PC/Workstation
non-realtime apps as the first concern. Extensions can always follow.



>
> Another possiblity would be to keep the name simple (Grace.Lists), and
> give the bounded version its own name when/if the time comes. Something
> like "Circular_Lists" (or Booch's "Ring") might be a possibility. This
> concept extends to Maps too, as we could call them "Maps" and "Hashes"
> rather than "Maps.Unbounded" and "Maps.Bounded". Not only is this a
> simpler structure, we no longer have the name talking about internal
> features of the structure instead of external features. That could be
> good enough for real-time and embedded folks if we document its use (or
> lack of use) of heap properly.
>
No reason I can think of not to use new names if we change the underlying
implementation to create a new kind of structure. I could see doing
something like "Grace.Lists" and "Grace.Static_Lists" or any variant that
some dedicated word-scientist would care to come up with. Avoiding saying
anything about the underlying implementation is desirable, but I wouldn't
insist if the alternative is to go through linguistic gyrations to get
there.

OTOH, this is all kind of "new" and someone has to invent names for new
things. So why couldn't we just rectally extract names for new components
that don't necesarily have anything to do with anything?

Grace.Lists - a dynamically linked list.
Grace.Gazorenthorpes - a statically allocated list with a maximum upper
bound.
Grace.Blivets - Like a Gazorenthorpe only with task safety built in.
Grace.Doohickies - Like a map, but static.

We can probably do this all day long - maybe even get a CS book written
about it and be immortalized in the annals of Geekdom forever. :-)


> But the argument for consistency with Ada.Strings.* is fairly compelling
> too.
>
I feel your compellation! :-) I'd like to be consistent with what has gone
before as well. But maybe its time to break with the past? Didn't Mark Twain
say "A foolish consistency is the product of little minds..." ?

This is a tough call, but I think I'd prefer to go with coming up with a
separate name for a list or map that had a significantly different behavior.


>
>
> I'm curious if other people feel this way. I'd lean towards
> "Grace.Lists", as the standard Ada library is equally flat, our list of
> components may not end up being large, and there isn't liable to be much
> common code sitting in the "Components" spec. But I'm not married to the
> idea. We certianly need to name for proper growth, as renaming files in
> CVS is kind of a kludge.
>
Well, maybe there is no reason we can't mix-n-match. If we don't see some
general category of "Containers" being likely - just Lists & Maps (and
variant implementations thereof) then maybe it doesn't need another layer. I
could envision at a later point doing something like "Grace.XML",
"Grace.XML.DOM", "Grace.XML.SAX" and so on if we did want to add something
that had logical sub-domains and/or deeper hierarchy.

My brain seems to like having a phylogenetic tree around for some reason.
Something like: <Library>.<Problem Domain>.<Specific Tool> would seem to be
sufficient to keep my brain happily amused and tranquil in the beautiful
serenity that can only come from a sublime sense of order. How does the rest
of the world feel?

Of course, if we got rid of the "Grace" part and just went with a bunch of
separate libraries under the <Problem Domain>.<Specific Tool> kind of thing,
we'd have categorization without so deep a tree. But then we lose any sense
of a unified library. No really perfect answers out there, are there?


>
> Yeah, that would be a good start. Right now in addtion to this I'm
> trying to figure out if I need to buy 3 smaller child car seats or a
> larger car. :-(
>

I hear minivans are nice. (Wasn't there a parody of the "Spiderman" theme
song called "Married Man" that alluded to minivans? Here we go:
http://www.thebigshow.com/BITPAGES/MARRDMAN.HTM) I should watch it - my
lovely bride could easily take umbrage and seek revenge by coming home with
a fake-wood pannel station wagon. :-)

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