From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6c424a2d310d290
X-Google-Attributes: gid103376,public
From: Brian Rogoff <bpr@shellx.best.com>
Subject: Re: Ada Generic Library (very) preliminary release
Date: 1997/07/09
Message-ID: <Pine.SGI.3.95.970709082112.10832B-100000@shellx.best.com>#1/1
X-Deja-AN: 255762203
References: <Pine.SGI.3.95.970708195446.25610A-100000@shellx.best.com>
 <33C39534.E8DAC63D@elca-matrix.ch>
Newsgroups: comp.lang.ada
Date: 1997-07-09T00:00:00+00:00
List-Id: <comp.lang.ada>


On Wed, 9 Jul 1997, Mats Weber wrote:
> Just had a fast look at it, here are a few comments:
> 
> - A minor glitch: all files have cr lf as line separators, but most unices
> prefer just a single line feed. I had to pass them through
> 
> for f in *
> do
>    cat $f | tr -d \\015 >/tmp/xuixuixui
>    mv /tmp/xuixuixui $f
> done
> 
> before I could watch them comfortably.

Noted. I'll fix that.

> - Many components are just plain record types, where I think good Ada 95 style
> would make them tagged types for several reasons: automatic finalization and
> possibility of inheritance among others.

Deliberate choice. STL uses no dynamic dispatch, and strives for the
efficiency of "hand coded C". While it may not be there, automatic
finalization of components won't help the Ada version. 

Besides, you can make your own "safe" AGL from primitive components, the 
other way is an abstraction inversion.

> - I don't know STL so my commments are from a "neutral" point of view.
> 
> - Some components need a Nil constant of the Element_Type, some not. I think
> this should be more uniform (I don't like that Nil convention BTW).

Yes, the component interfaces are not as uniform as I'd like them. I agree, 
that Nil element type is wrong. However, the Nil node in Red_Black_Trees 
will probably stay.

> - The components taking type Element_Type is private as a generic parameter
> should also have 
>    with funciton "=" (l, r : element_Type) return Boolean;
> to avoid the reemergence of predefined "=".

Good point. In the ordered containers, I'll ultimately provide a three way 
compare for element types, so this won't be a problem there.

> - Red_Black_Trees should raise an exception when trying to insert a duplicate
> element and Insert_Always is False.

Agreed.

> - Many things are done in the visible part of packages, but could very well be
> hidden, e.g. Ordered_Maps exports its implementation (instance of
> Red_Black_Trees), Read_Black_Trees exports the type Value_Ref_Type, which is
> not used in the specification.
> 
> - Maybe I'll make more comments if I get to look at it a bit closer.

Thanks. Some of the things you mentioned will be fixed.

-- Brian