comp.lang.ada
 help / color / mirror / Atom feed
From: Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
Subject: Re: signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style)
Date: Thu, 07 Aug 2003 12:12:39 +0200
Date: 2003-08-07T12:12:39+02:00	[thread overview]
Message-ID: <jr24jv8sdug2s1ru7kf6vkspj8kh9oltvj@4ax.com> (raw)
In-Reply-To: bgrgj7$38u$1@a1-hrz.uni-duisburg.de

On Wed, 6 Aug 2003 18:15:03 +0000 (UTC), Georg Bauhaus
<sb463ba@d2-hrz.uni-duisburg.de> wrote:

>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.

Iiterally read - no interfaces needed in a design process! Maybe, you
meant a hacking process. (:-)) 

>:>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 ...

How this is better than (if were possible)

type X is abstract ...;
function count (thing: X) return Natural is abstract;

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

You claim that different X are incompatible, but have you asked
yourself, to what they are? The interface tells nothing about it. On
the contrary it tells how they *are* compatible, they all are
copyable, have "count" etc. Now the only incompatibility is a
limitation that a class-wide object cannot be a member. But this has
nothing to do with interfaces. It is an implementation detail. And
after all why not:

type Y is new X with record
   nfrob : Natural;
end record;

>: 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.

I hope you do not propose "write-first" approach. (:-)) Interface is
not a result, it is the starting point when we are thinking about a
program. You can either formalize it in the code if a language helps,
or leave it for a reader to try to figure interface out.

>: 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).

If you use it, then it fits. If it does not, then you cannot use it.
It is no matter whether you state it explicitly or implicitly. But it
well matters for a reader.

>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.

I do not see any difference. With inheritance the provider does not
know whether you derive or not. Instantiation can be viewed as sort of
inheritance from some implicitly declared abstract type with a
consequent type cloning (to avoid mixing of siblings).

>:>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?

My generic package implementing fuzzy numbers has about 30 formal
parameters.

>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.

My point is, "to provide a function to compare" = "to make
comparable". It is SAME.

You might object, that one should foresee whether a type should be
comparable or that making comparable is "global". This all are just
limitations of ADT implementations we presently have. For example,
with supertyping and multiple inheritance you can always make one
given type a subtype of another given type.

>:>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.)

But a class-wide parameter already does the trick.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de



  reply	other threads:[~2003-08-07 10:12 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-30 11:32 XML DOM Binding for Ada 95 - matter of style DENNY VRANDECIC
2003-07-30 12:33 ` Martin Dowie
2003-07-30 15:20   ` Denny Vrandecic
2003-07-30 16:33     ` Stephen Leake
2003-07-31 10:57       ` Marin David Condic
2003-07-31 11:27         ` Preben Randhol
2003-07-31 13:10           ` Matthew Heaney
2003-07-31 19:04             ` Simon Wright
2003-08-02 14:40               ` Matthew Heaney
2003-07-31 20:25             ` Randy Brukardt
2003-08-01 11:46           ` Marin David Condic
2003-08-02  3:40             ` Matthew Heaney
2003-08-02 12:08               ` Marin David Condic
2003-08-02 14:46                 ` Matthew Heaney
2003-08-02 21:25                   ` Ed Falis
2003-08-05 19:59                   ` Marin David Condic
2003-08-03 16:42                 ` Matthew Heaney
2003-08-04  8:04                   ` Dmitry A. Kazakov
2003-08-05  8:00                     ` Georg Bauhaus
2003-08-05 11:46                       ` Dmitry A. Kazakov
2003-08-05 13:34                         ` Georg Bauhaus
2003-08-06  9:03                           ` Dmitry A. Kazakov
2003-08-06 18:15                             ` signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style) Georg Bauhaus
2003-08-07 10:12                               ` Dmitry A. Kazakov [this message]
2003-08-07 16:22                                 ` signature like constructions Georg Bauhaus
2003-08-08  8:31                                   ` Dmitry A. Kazakov
2003-08-08 10:12                                     ` Robert I. Eachus
2003-08-08 13:29                                       ` Dmitry A. Kazakov
2003-08-08 19:37                                         ` Robert I. Eachus
2003-08-09  0:58                                           ` Alexander Kopilovitch
2003-08-09  7:39                                             ` Robert I. Eachus
2003-08-10  1:30                                               ` Alexander Kopilovitch
2003-08-10  4:11                                                 ` Robert I. Eachus
2003-08-11 10:25                                           ` Dmitry A. Kazakov
2003-08-08 23:44                                         ` Alexander Kopilovitch
2003-08-11  9:54                                           ` Dmitry A. Kazakov
2003-08-11 14:59                                             ` Alexander Kopilovitch
2003-08-12  9:54                                               ` Dmitry A. Kazakov
2003-08-13 22:28                                                 ` Alexander Kopilovitch
2003-08-09  8:32                                       ` Simon Wright
2003-08-09 15:32                                         ` Robert I. Eachus
2003-08-07 12:52                             ` XML DOM Binding for Ada 95 - matter of style Matthew Heaney
2003-08-07 15:03                               ` Dmitry A. Kazakov
2003-08-07 12:28                           ` Matthew Heaney
2003-08-05 20:05                   ` Marin David Condic
2003-07-30 16:34     ` Martin Dowie
2003-07-30 17:54 ` tmoran
replies disabled

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