On May 7, 9:48 pm, "ophir.gef...@[EMAIL PROTECTED]
" <ophir.gef...@[EMAIL PROTECTED]
>
wrote:
> On May 8, 7:09 am, "Jeffrey R. Carter"
>
>
>
> <spam.jrcarter....@[EMAIL PROTECTED]
> wrote:
> > ophir.gef...@[EMAIL PROTECTED]
wrote:
>
> > > * queues.ads:
> > > with Ada.Text_IO;
> > > generic
> > > type Item is private;
> > > with procedure Item_Put(The_Item : in Item);
>
> > Item_Put has exactly one parameter.
> Hi
> Thanks for the quick reply
>
> The problem is that the package needs to know how to handle most non-
> limited types like Integer, String, Client, Plane, Book, Do***ent, ...
> The Put procedure in any of those might and should be different from
> Put Integer.
>
> And I don't want to force the package user to declare a special Put
> procedure with only one var.
I think you should anyway, even if you think you don't want to. The
generic is defined correctly; the generic formal subprogram reflects
exactly what you need---an output routine that takes one parameter of
type Item. In most cases, *somebody* is going to have to define a
routine like that, somewhere. And if the package that defines, say,
Do***ent, doesn't provide a routine with exactly that profile (maybe
the only Do***ent output routines take page-dimension parameters),
then whoever instantiates your generic is going to have to write a
wrapper routine anyway. It's pretty common in my experience to have
to write small routines like this for generic instantiation purposes,
and I don't see that changing until they decide to add something like
Lambda expressions to Ada, which I don't think will be happening soon.
In fact, if the Put routines of Integer_IO didn't have default
parameters (so that every time you called Put you would have to
explicitly specify the Width and Base), it would seem normal, and not
particularly burdensome, to write a one-parameter wrapper routine in
order to instantiate the generic. I think only reason there's an
issue, and that you "don't want to" make the users declare "special"
Put routines, is that Put *looks* like it has just one parameter the
way it's normally used. But since it doesn't, you're getting this
error which is surprising, and that makes it seem like users are being
forced to do something they shouldn't have to do. Probably, the
solution is for the compiler to detect this case and display a more
helpful error message, but other than that I don't think this is a
problem.
-- Adam
|
