From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c9629eba26884d78 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-07 03:07:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada 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 Message-ID: References: <3F2A5303.6080902@noplace.com> <3F2BA9C8.9030700@noplace.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1060250843 29024707 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:41228 Date: 2003-08-07T12:12:39+02:00 List-Id: On Wed, 6 Aug 2003 18:15:03 +0000 (UTC), Georg Bauhaus wrote: >Dmitry A. Kazakov wrote: >: On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus >: wrote: >: >:>Dmitry A. Kazakov 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