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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,da85d9aaf769b16a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!feeder.news-service.com!news.astraweb.com!border5.a.newsrouter.astraweb.com!news-out2.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Generic package parameters not externally visible : what's the rational ? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <10eygvuzeit9g.xwy2wanxoxgf$.dlg@40tude.net> <1kf8mo4r9lqxg.1tdhqe6femt9m.dlg@40tude.net> <1r8etjwa9k46n.3pyj04jn686o$.dlg@40tude.net> <1trjf9wxhbsqb$.14uxfibpc7k8x$.dlg@40tude.net> <19ee7f4e-513a-4caf-9822-4610ff2155b2@m16g2000yqc.googlegroups.com> <1ueb9d0h9nmm3$.11lt1wv42yxvt.dlg@40tude.net> <67b00f8a-3d12-48c9-ad5a-34980cf82e08@37g2000yqm.googlegroups.com> <11k5zsz6ne6n5$.ds2jp646tltk.dlg@40tude.net> <678f416b-c31b-4b51-88df-1e8917c111c0@n35g2000yqm.googlegroups.com> <1og9wz7f75x0r.1fknswx76xyyz$.dlg@40tude.net> <64f7c9d4-df3d-4313-985d-1191991a1de6@l13g2000yqb.googlegroups.com> Date: Fri, 6 Nov 2009 14:27:36 +0100 Message-ID: <1xzw91gfd3iaw.1j1rjfuvb23r9$.dlg@40tude.net> NNTP-Posting-Date: 06 Nov 2009 14:27:36 CET NNTP-Posting-Host: 8397dce1.newsspool3.arcor-online.net X-Trace: DXC=[YG?@5R^HJ5;]cDoEWD6A4McF=Q^Z^V384Fo<]lROoR18kF7enW;^6ZC`4IXm65S@:3>?UPK0L^P=172 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:9015 Date: 2009-11-06T14:27:36+01:00 List-Id: On Fri, 6 Nov 2009 04:19:10 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote: > On 5 nov, 15:09, "Dmitry A. Kazakov" > wrote: >> On Thu, 5 Nov 2009 04:16:11 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote: >>> On 5 nov, 12:00, "Dmitry A. Kazakov" >>> wrote: >>>> I am using "Generic_" because it is almost impossible to do anything >>>> otherwise if you have really many generics. And I do, because I have to. >>> Then, may be a point to discuss about : when using a "_Mixin" packages >>> (or "_Facet", after Rosen, this is the same), as a "_Mixin" package is >>> generic (this would not make sense otherwise), the "Generic_" prefix >>> may not be needed when the package is "_Mixin". Or perhaps >>> "_Mixin" (nor "_Facet") should not be used after-all, and only >>> "Generic_" should be (showing no difference between "_Mixin" and >>> others "Generic_"). >> >> Sounds interesting. Can you give some examples? > You are more experienced than I am, so this may not sounds so much > interesting after-all > > I was talking about the "_Mixin" design pattern, which is a suggested > way to do something like MI (Multiple Inheritance) with Ada. I think > you do not use it, as your talked about some personal success stories > you had with the Interface construct, and "_Mixin" is supposed to be > the generic way to do most of what Interface can do. In fact I am forced to use both because MI is not supported for concrete types. I have MI only in the interfaces. There are generics to provide implementations for the concrete types implementing those interfaces. It is awfully complex, I hate it, but I know no other way to do this. The problem of naming is only of a facet of the bigger mess. It is a consequence of a bad pattern, but that pattern is imposed by the language. > In the previous > context, I was to say that as the "_Mixin" design pattern only makes > sense with generics, if a package as the "_Mixin" suffix, there is no > need to add the "Generic_" prefix, because "_Mixin" implies the > package is generic. Then, as "_Mixin" and "Generic_" both means > "generic", I was simply wondering if "_Mixin" was to be really used or > not (finally, I think it is of real interest, so I did not drop > "_Mixin" in favor or "Generic_"). Yes, that was my question too. It looks to me an interesting idea to name generics after their roles. Mixin is probably too general, there are several scenarios where generics are used. MI emulation is one case. Another (also mixin) is that when you had layered protocols and did not want to specify the transport layer. You could make it a generic parameter, an abstract base type from which higher levels derive. Yet another is parallel hierarchies of types, like of objects and of handles to them etc. Maybe such common patterns could be classified and given recognizable suffixes or prefixes instead of rather empty Generic_, which adds no value beyond merely separating the name space. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de