Preferred method for bringing in operators

Preferred method for bringing in operators

[Marin David Condic]

This is a question about style and preferences, rather than something purely
technical. I just want to know what people prefer and if there are any
reasons to consider one style superior to another...

Suppose you build a class to represent a container of some objects. The
objects are just stored and retrieved from the container in no particular
order. Now you want to derive a child class from the container only in this
case you want to store and retrieve the objects in sorted order. That means
you have to somehow extend the class to bring in one or more comparison
operations for the object being stored. A variety of solutions exist:

1) Make the child generic and bring in the comparison functions needed in
the generic parameter list. Some version of 'with function "<" (Left..." The
user then needs to create an instance of the child providing the operation
as a parameter.

2) Declare in the child package an abstract function to operate on the
stored objects and provide comparisons. The user then needs to create one
more derivation from the child package to provide the abstract operation.

3) Extend the class for the stored objects to have a "Ordered Object" that
has abstract functions for comparisons. Allow only objects of this class to
be put in the list. The user must extend the object class to provide the
functions. (May have problems with compatibility with the parent class -
type conflicts, etc.)

4) Do something to declare an access type to the function and expect the
user to provide the access value as part of the creation of the list. (Don't
really like this answer much. Where do the declarations go and how would
they look?)

There may be other ways of doing the feline-epidermal-removal, but these are
the ones I can think of. I'm curious about what others think would be the
best idiom for doing this?

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

Re: Preferred method for bringing in operators

[Stephen Leake]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> This is a question about style and preferences, rather than something purely
> technical. I just want to know what people prefer and if there are any
> reasons to consider one style superior to another...
> 
> Suppose you build a class to represent a container of some objects. The
> objects are just stored and retrieved from the container in no particular
> order. Now you want to derive a child class from the container only in this
> case you want to store and retrieve the objects in sorted order. That means
> you have to somehow extend the class to bring in one or more comparison
> operations for the object being stored. A variety of solutions exist:
> <snip>

You first need to decide if you are using a tagged type approach, or a
generic approach. Since you said "class", I guess you are leaning
towards tagged types, but then you talk about generics, so I'm
not clear.

For my answer to both approaches, see
http://users.erols.com/leakstan/Stephe/Ada/sal.html

Specifically, for the generic approach, sal-gen-alg.ads defines the
notion of an algoirthm on a container, sal-gen-alg-find_linear.ads
extends that to a 'find' alorgithm. Then
sal-gen-alg-find_linear-sorted.ads extends that to a linear sorted
list, and sal-gen-alg-find_binary.ads extends it to binary searching
on a sorted container.

For the tagged type approach, see sal-poly-alg.ads,
sal-poly-alg-find_linear.ads. These are also generics, but the basic
container is a tagged type.

Hope this helps :).

-- 
-- Stephe

Re: Preferred method for bringing in operators

[Marin David Condic]

Yeah. That generates some ideas at least. Out of all the possible
approaches, this is one of them! :-)

I'm dealing basically with a tagged record and working from the polymorophic
approach. Its not that I don't like generics - its just that in this case I
want to be able to keep extending the classes to have new features as the
need arises & generics tend to be less amenable to this. Besides, from
looking at your generic example, I can see what I dislike about the
approach - the need to build long lists of generic formal parameters and the
difficulty this implies for the end-user. It has its advantages in many
cases, but I'd like to avoid it if possible. Still, if all I want is to get
a user defined "<" operator, this isn't so bad. I'm just not sure that it is
the "Object Oriented Ada Way" - or at least a way that one won't regret as
one uses and extends the package.

On another matter: It looks like you're doing some things similar to things
I have attempted - deriving tagged types from Ada.Finalization.Controlled.
I'm using Gnat 3.13p and have had trouble mixing this with various stream
operations. (What would appear to be legal & workable when it *doesn't*
derive from Finalization ends up crashing when it *does* derive from
Finalization.) I'm wondering if you have experienced similar troubles and if
so did you find a workaround? Are there other Ada compilers on which this
may have worked properly?

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


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uith9nbra.fsf@gsfc.nasa.gov...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
>
> > This is a question about style and preferences, rather than something
purely
> > technical. I just want to know what people prefer and if there are any
> > reasons to consider one style superior to another...
> >
> > Suppose you build a class to represent a container of some objects. The
> > objects are just stored and retrieved from the container in no
particular
> > order. Now you want to derive a child class from the container only in
this
> > case you want to store and retrieve the objects in sorted order. That
means
> > you have to somehow extend the class to bring in one or more comparison
> > operations for the object being stored. A variety of solutions exist:
> > <snip>
>
> You first need to decide if you are using a tagged type approach, or a
> generic approach. Since you said "class", I guess you are leaning
> towards tagged types, but then you talk about generics, so I'm
> not clear.
>
> For my answer to both approaches, see
> http://users.erols.com/leakstan/Stephe/Ada/sal.html
>
> Specifically, for the generic approach, sal-gen-alg.ads defines the
> notion of an algoirthm on a container, sal-gen-alg-find_linear.ads
> extends that to a 'find' alorgithm. Then
> sal-gen-alg-find_linear-sorted.ads extends that to a linear sorted
> list, and sal-gen-alg-find_binary.ads extends it to binary searching
> on a sorted container.
>
> For the tagged type approach, see sal-poly-alg.ads,
> sal-poly-alg-find_linear.ads. These are also generics, but the basic
> container is a tagged type.
>
> Hope this helps :).
>
> --
> -- Stephe

Re: Preferred method for bringing in operators

[Stephen Leake]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> Yeah. That generates some ideas at least. Out of all the possible
> approaches, this is one of them! :-)
> 
> I'm dealing basically with a tagged record and working from the polymorophic
> approach. Its not that I don't like generics - its just that in this case I
> want to be able to keep extending the classes to have new features as the
> need arises & generics tend to be less amenable to this. Besides, from
> looking at your generic example, I can see what I dislike about the
> approach - the need to build long lists of generic formal parameters and the
> difficulty this implies for the end-user. It has its advantages in many
> cases, but I'd like to avoid it if possible. Still, if all I want is to get
> a user defined "<" operator, this isn't so bad. I'm just not sure that it is
> the "Object Oriented Ada Way" - or at least a way that one won't regret as
> one uses and extends the package.

The polymorphic tagged type approach is definitely the "Class Oriented
Way". I think the pure generic approach defines equally good
"Objects"; they just aren't "Classes".

> On another matter: It looks like you're doing some things similar to
> things I have attempted - deriving tagged types from
> Ada.Finalization.Controlled. I'm using Gnat 3.13p and have had
> trouble mixing this with various stream operations. (What would
> appear to be legal & workable when it *doesn't* derive from
> Finalization ends up crashing when it *does* derive from
> Finalization.) I'm wondering if you have experienced similar
> troubles and if so did you find a workaround? 

No, I have not played with Streams much. I do play with storage pools,
and had trouble with GNAT 3.13 on that (3.14 fixes it).

> Are there other Ada compilers on which this may have worked
> properly?

I tested an early version of this stuff on ObjectAda, and had no
problems. But I've given up on that, partly because it doesn't have 64
bit ints, partly because GNAT has way better error messages, but
mostly because I don't have time to do both.

-- 
-- Stephe

Re: Preferred method for bringing in operators

[tmoran]

>I have attempted - deriving tagged types from Ada.Finalization.Controlled.
>I'm using Gnat 3.13p and have had trouble mixing this with various stream
>operations. (What would appear to be legal & workable when it *doesn't*
>derive from Finalization ends up crashing when it *does* derive from
>Finalization.) I'm wondering if you have experienced similar troubles and if
  Crash how?  I haven't noticed any problem (yet) - what should be
avoided?

Re: Preferred method for bringing in operators

[Marin David Condic]

I've got a couple of cases where attempting to read or write tagged records
from/to a stream file ends up raising Program_Error if the tagged types are
derived from Ada.Finalization.Controlled. If you change the code to *not*
derive from Controlled, it works fine. The examples that illustrate this are
a bit long and hard to cut down to manageable size. IIRC, I reported at
least one instance of it to ACT, so maybe they looked into it & fixed it.
I'm wondering if maybe similar problems exist elsewhere. I'd kind of like to
test the code I've got that does this against a different compiler to gain
some insight into its correctness or possibly find alternative ways of
getting the job done. Its a kind of a tough spot when dealing with data
structures where you want to go "I'd like to save this to a stream file
*and* I'd like to control what happens to it on assignment" and have to make
a choice between one or the other.

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


<tmoran@acm.org> wrote in message
news:Ibs07.149836$%i7.100699762@news1.rdc1.sfba.home.com...
>   Crash how?  I haven't noticed any problem (yet) - what should be
> avoided?