Re: signature like constructions

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

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
Newsgroups: comp.lang.ada
References: <slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no>   <apGWa.1581$jp.254@newsread4.news.pas.earthlink.net> <3F2BA9C8.9030700@noplace.com> <SXaXa.5251$jg7.4768@newsread3.news.pas.earthlink.net> <ti3sivgstvvmh3j7399j0prvlifsm8j5it@4ax.com> <bgno68$lpd$1@a1-hrz.uni-duisburg.de> <qp5viv8jdbasoc2s83hrrv0f4mtfvp0mnn@4ax.com> <bgoboh$pae$1@a1-hrz.uni-duisburg.de> <egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com> <bgrgj7$38u$1@a1-hrz.uni-duisburg.de> <jr24jv8sdug2s1ru7kf6vkspj8kh9oltvj@4ax.com>
Organization: GMUGHDU
User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/831))

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>:>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. (:-)) 

Why should I add hash(x: Point) to the interface of a 2D point?
In the generics case, the "interface of the type", and the "interface
of the package instance" need not be too closely coupled.
Hashing can be provided elsewhere.
(Matthew Heaney has explained that you might anticipate possible
uses of your types, but do I have to expect and design my (x, y) pairs
so that they can become part of a data structure that requires a
hash value for them? Just to stay in inheritance land?)

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

It is better because it is possible :-)

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

No. Count need not be an operation of X. It might as well be implemented
elsewhere, for example using two inquiry functions from the "interface"
of the actual for X, or three from another, unrelated actual.

Also,

generic
  type X is private;
  type Y is private;
  with function between(this_one: X; that_one: Y) return Float;
package ...

How do I do this using your next example, and do it in Ada, that is,
not in CLOS, Smalltalk, or Haskell, with MI of interfaces?

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

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

I design the "signature package", which has the interface
I want (mostly after the keyword "package"). The focus is not 
necessarily on the formal type's restrictions.

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

It need not even be of a tagged type, so why will it fit?
And if you consider X and Y above, they need not be part of the same
type tree.

Say we had full MI. Would you prefer to to have

  type T is new X and Y with private;  -- not Ada
  function between(combined: T) return Float;

and then name clash resolution all over the place?

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

Your type will have about 30 things delcared, too, won't it?
(I'm not advocating the replacement of OO with generics BTW,
just trying to point out that you can, conceptually, escape the
type hierarchy using generics, and then use the instance's
subprograms, thinking of them as an interface.)

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

Indeed I will will be forced to foresee this in Ada.

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

Some Questions:

AFAICS, there might be multiple inheritance of interfaces, but not MI
in Ada 200X?

If I don't want to see but three operation of type X, and two of Y,
how can I limit the visibility of the others?
Use export lists like in Eiffel?

How about libraries without the possibility of changing the base types?



Georg