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-06 11:15:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!eusc.inter.net!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style) Date: Wed, 6 Aug 2003 18:15:03 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <3F28F61D.4050504@noplace.com> <3F2A5303.6080902@noplace.com> <3F2BA9C8.9030700@noplace.com> NNTP-Posting-Host: d2-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1060193703 3358 134.91.1.15 (6 Aug 2003 18:15:03 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Wed, 6 Aug 2003 18:15:03 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/831)) Xref: archiver1.google.com comp.lang.ada:41221 Date: 2003-08-06T18:15:03+00:00 List-Id: 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. :>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