signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style)

[Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de>]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus
: <sb463ba@d2-hrz.uni-duisburg.de> wrote:
: 
:>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>: Isn't signature just another word for interface? Does not a set of
:>: subroutines with compatible signatures constitute an interface for
:>: some abstract/real type? One could long for a better way to describe
:>: and manage interfaces, but there is no real alternative to them.
:>
:>You don't need to know about them during the design process,
 
: Really?

Yes. See below.
 
:>but you can construct "signature instances" like so:
:>
:>generic
:>  type X is private;
:>  function count(thing: X) return Natural;
:>  procedure stretch(thing: in out X);
:>...
:>
:>and then instantiate "..." with whatever actuals seem fit.
:>This doesn't require that the provider of the units from which
:>X, count, etc. are taken, has to know beforehand that his/her types,
:>functions, or whatever will be used this way.
: 
: It is an illusion of freedom. In fact, from the specification above,
: it is clear that X is private, i.e. has a default constructor, a copy
: constructor, an assignment, count, stretch. So it is pretty much said
: about possible X, and it is in fact an *interface*.

Uhm, that says something about the formals, but not everything about
the things you put inside the "signature package". If you have

generic
  type X is private;
  with function count(thing: X) return Natural;
package Foo is

  type Y is record
     nfrob: Natural;
     wrapped: X;
  end record;

  -- ...
  function calculate_mythical_number(item: Y) return Float;
  -- this is the interesting measure of all the incompatible
  -- X items in the world
end Foo;

Then when you instantiate, this package will offer an interface
to Y, in a general sense, because it is a natural thing for a
package to have one ;-). But ...

: instantiate, the actual type is checked against that interface.

Uhm, against that interface is not what I've had in mind, I think
I have failed to explain. So, instead, the interface is the "result"
of the "signature package" instantiation.

: how it differs from interface inheritance, except from techical
: details? It does not.

I think it does, if you think of this kind of interface.
Anything that can be used as actual for X (and count) can
be used without having to fit in some inheritance tree (or graph).
It can, but it _need_ not, which IIRC is the point of this kind
of "signature". You construct items that have some interface
by way of the subprograms of the *instance*. The provider of X
does _not_ have to know this.

:>Actually, you can pass operations of a tagged type as actuals.
: 
: Yes, this is a great disadvantage of generics. You have to explicitly
: specify everything you need.

In view of the above, how is this a disadvantage?

In another view, if you want something, call it T, that can be
compared to another T, or which needs to be hashed, then the
generic actuals for comparison or hashing need not be associated
with T, which I find can be an advantage. The provider of T does not
have to make T "comparable" or "hashable" by adding operations
to T.


:>Can this be done with virtual member functions in C++?
: 
: You mean to pass a dispatching operation to a template?

Exactly. (This way, you get a collection of virtual
"service routines" from actual parameters, which
can be used to provide the functionality needed in the package's
subprograms.)


Georg