comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Generic package parameters not externally visible : what's the rational ?
Date: Fri, 6 Nov 2009 14:27:36 +0100
Date: 2009-11-06T14:27:36+01:00	[thread overview]
Message-ID: <1xzw91gfd3iaw.1j1rjfuvb23r9$.dlg@40tude.net> (raw)
In-Reply-To: 64f7c9d4-df3d-4313-985d-1191991a1de6@l13g2000yqb.googlegroups.com

On Fri, 6 Nov 2009 04:19:10 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote:

> On 5 nov, 15:09, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 5 Nov 2009 04:16:11 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote:
>>> On 5 nov, 12:00, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> 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



  reply	other threads:[~2009-11-06 13:27 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-26  8:58 Generic package parameters not externally visible : what's the rational ? Hibou57 (Yannick Duchêne)
2009-10-26 11:05 ` Ludovic Brenta
2009-10-26 15:02   ` Robert A Duff
2009-10-27  1:06   ` Hibou57 (Yannick Duchêne)
2009-10-26 14:56 ` Robert A Duff
2009-10-27  3:03   ` Hibou57 (Yannick Duchêne)
2009-10-27 21:08   ` Randy Brukardt
2009-10-27 21:36     ` Jeffrey R. Carter
2009-10-27 22:03       ` Hibou57 (Yannick Duchêne)
2009-10-27 22:19         ` Jeffrey R. Carter
2009-10-28 19:07         ` Randy Brukardt
2009-10-29 12:18           ` Hibou57 (Yannick Duchêne)
2009-10-29 22:56             ` Randy Brukardt
2009-10-30  0:10               ` Hibou57 (Yannick Duchêne)
2009-10-27 22:04       ` Hibou57 (Yannick Duchêne)
2009-10-27 23:37       ` Robert A Duff
2009-10-27 23:41         ` Jeffrey R. Carter
2009-10-27 23:34     ` Robert A Duff
2009-10-28  2:19       ` Hibou57 (Yannick Duchêne)
2009-10-28 19:12         ` Randy Brukardt
2009-10-29  7:34           ` Stephen Leake
2009-10-29 12:21           ` Hibou57 (Yannick Duchêne)
2009-10-29 13:10             ` AdaMagica
2009-10-29 15:11               ` Georg Bauhaus
2009-10-29 19:28                 ` Jeffrey R. Carter
2009-10-29 20:27                   ` Georg Bauhaus
2009-10-30 10:30               ` Stephen Leake
2009-10-30 17:53             ` Ludovic Brenta
2009-10-31  2:10               ` Hibou57 (Yannick Duchêne)
2009-10-30  5:19           ` Hibou57 (Yannick Duchêne)
2009-10-28  9:09     ` Dmitry A. Kazakov
2009-10-28 19:19       ` Randy Brukardt
2009-10-29  8:36         ` Dmitry A. Kazakov
2009-10-29 23:03           ` Randy Brukardt
2009-10-30  8:51             ` Dmitry A. Kazakov
2009-10-30 10:25           ` Stephen Leake
2009-10-30 19:32             ` Dmitry A. Kazakov
2009-10-31  2:06               ` Hibou57 (Yannick Duchêne)
2009-10-31  9:14                 ` Dmitry A. Kazakov
2009-11-03  8:25                   ` Hibou57 (Yannick Duchêne)
2009-11-03  9:59                     ` Dmitry A. Kazakov
2009-11-05 10:38                       ` Hibou57 (Yannick Duchêne)
2009-11-05 11:00                         ` Dmitry A. Kazakov
2009-11-05 12:16                           ` Hibou57 (Yannick Duchêne)
2009-11-05 14:09                             ` Dmitry A. Kazakov
2009-11-06 12:19                               ` Hibou57 (Yannick Duchêne)
2009-11-06 13:27                                 ` Dmitry A. Kazakov [this message]
2009-10-31  2:08               ` Hibou57 (Yannick Duchêne)
2009-10-31 12:44               ` Stephen Leake
2009-11-01 11:37                 ` Dmitry A. Kazakov
replies disabled

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