comp.lang.ada
 help / color / mirror / Atom feed
From: Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>
Subject: Re: Generics not overloadable
Date: 10 Dec 2001 11:15:55 -0500
Date: 2001-12-10T16:18:38+00:00	[thread overview]
Message-ID: <u7krvuk3o.fsf@gsfc.nasa.gov> (raw)
In-Reply-To: pcKQ7.19034$wL4.24049@rwcrnsc51

"Mark Lundquist" <mlundquist2@attbi.com> writes:

> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0111281941.2620b70a@posting.google.com...
> > Ted Dennison<dennison@telepath.com> wrote in message
> news:<VGcN7.41331$xS6.69936@www.newsranger.com>...
> >
> > > It annoyed me too when I discovered it
> >
> > I find it hard to believe that it would be easy to come
> > up with an example where it would help the reader to
> > name two visible generic units with the same name.
> 
> Why should it make a difference whether they are generic?  The principle is
> the same.  As for examples, just about anything will do, but here's one
> (self-explanatory, I trust)...

I'll weigh in with Robert here; I find this abhorrent :).

>     generic with procedure Action (On : Item); procedure Apply (Over
>     : Collection);
> 
>     generic
>         with procedure Action (On : Item; Continue : out Boolean);
>     procedure Apply (Over : Collection);
> 
>     generic
>         with procedure Action (On : Item);
>     procedure Apply (Start, Finish : in Iterator);
> 
>     generic
>         with procedure Action (On : Item; Continue : out Boolean);
>     procedure Apply (Start, Finish : in Iterator);
> 
> The user should not have to remember a different fiddly specialized name for
> each variant.   It's much more natural, and easier on the user,  if each can
> be called simply "Apply".

This seems true, until you get to the instantiations. Taking your
approach, all three would be identical, assuming appropriately
overloaded procedures 'My_Action':

procedure My_Apply is new Apply (Action => My_Action);
procedure My_Apply is new Apply (Action => My_Action);
procedure My_Apply is new Apply (Action => My_Action);

Obviously, the compiler has no chance to sort this out. But the
argument is that it is bad for the reader. Suppose we forgot one of
these (assuming there were some way to make it legal). Later, when we
try to call the missing My_Apply, the compiler says "no procedure
matching My_Apply is visible". So we come back to here and say "Yes it
is!". 

Too confusing. This is better:

procedure My_Apply is new Apply_Over_Boolean (My_Action);
procedure My_Apply is new Apply_Start_Finish (My_Action);
procedure My_Apply is new Apply_Start_Finish_Boolean (My_Action);

Now both the compiler and the reader can sort things out.
> 
> 
> >
> > Indeed, far too often overloading in Ada is misused to save the
> > bother of thinking of different names.
> 
> Maybe so, but not by me :-).  I take naming too seriously, if anything :-).
> Incidentally, I realized the reason for the language rule that makes it
> impossible to overload generics.  

I'm not sure you have; did you consider trying to instantiate your example?

-- 
-- Stephe



  reply	other threads:[~2001-12-10 16:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-28 21:10 Generics not overloadable Mark Lundquist
2001-11-28 21:29 ` Ted Dennison
2001-11-29  3:41   ` Robert Dewar
2001-11-29  5:49     ` R. Tim Coslet
2001-12-09 14:05     ` Mark Lundquist
2001-12-10 16:15       ` Stephen Leake [this message]
2001-11-29 10:41 ` Ian Wild
2001-11-29 19:10   ` Mark Lundquist
2001-11-30 22:38     ` Nick Roberts
  -- strict thread matches above, loose matches on Subject: below --
2001-11-28 17:44 Mark Lundquist
replies disabled

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