RE: Should MI be supported (was: Can MI be supported?)

RE: Should MI be supported (was: Can MI be supported?)

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Matthew Heaney [mailto:matthewjheaney@earthlink.net]
..
| Lionel.DRAGHI@fr.thalesgroup.com writes:
| 
| > That's where we differ. I feel much more confortable with Bob's
| > translation, because Colorable is not an object, it's a 
| "properties".
| 
| Perhaps, but I felt (and still do) that my translation was 
| more faithful
| to the C++ example.
...
| The mixin approach may translate better to the problem 
| description, but
| it's debatable whether it translates better to the C++ implementation.
| As usual, YMMV....

Yes, I agree with you that multiple views idiom match much better Hyman's
example than the Mixin's one.  

But note that i was not discussing this: I was just arguing that Mixin was
(in my opinion) a more natural implementation of this particular problem,
not a more natural translation of Hyman's code. 

-- 
Lionel Draghi

RE: Should MI be supported (was: Can MI be supported?)

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Matthew Heaney [mailto:matthewjheaney@earthlink.net]
...
| Did I think Bob's translation was very natural?  Not really, no.
| _

That's where we differ. I feel much more confortable with Bob's translation,
because
Colorable is not an object, it's a "properties".

My_Adapter is an Adapter, so inheritance apply.
My_Adapter is not a "colorable", so i won't inherit from some colorable
class.
Neither is "Colorable" a particular "role" of an Adapter.

It's just a characteristic (note that Colourable is an adjective, Adapter is
a noun), and so i use a Mixin.
You may perfectly use multiple views if you feel better with it. Hyman
choose MI instead of (templates + SI) because the code was simpler to write.
But in my opinion, mixin translate better the problem description. 

-- 
Lionel Draghi

Re: Should MI be supported (was: Can MI be supported?)

[Matthew Heaney]

Lionel.DRAGHI@fr.thalesgroup.com writes:

> That's where we differ. I feel much more confortable with Bob's
> translation, because Colorable is not an object, it's a "properties".

Perhaps, but I felt (and still do) that my translation was more faithful
to the C++ example.


> My_Adapter is an Adapter, so inheritance applies.  My_Adapter is not a
> "colorable", so i won't inherit from some colorable class.  Neither is
> "Colorable" a particular "role" of an Adapter.

What's interesting is that my example, I only exposed the root interface
types: Colorable_Type and Resizeable_Type.  I felt that in Hyman's
implementation, he exposed too much information; specifically, that
My_Object derived from Colorable_Adapter_Type and
Resizeable_Adapter_Type.

But that's only an implementation detail.  What's nice in the approach I
showed is that you only have to advertise that you support the root type
interface.  The fact that privately I "inherited" from
Colorable_Adapter_Type and Resizeable_Adapter_Type was only an
implementation detail, and therefore I was able to move it to the
private part of the spec.

Hyman: Is there a way to do that in C++?  Can you publicly inhterit from
ColorableType and privately inherit from ColorableAdapterType?


> It's just a characteristic (note that Colourable is an adjective,
> Adapter is a noun), and so i use a Mixin.  You may perfectly use
> multiple views if you feel better with it. Hyman choose MI instead of
> (templates + SI) because the code was simpler to write.  But in my
> opinion, mixin translate better the problem description.

The mixin approach may translate better to the problem description, but
it's debatable whether it translates better to the C++ implementation.
As usual, YMMV....

Re: Should MI be supported (was: Can MI be supported?)

[Hyman Rosen]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uu17c5bkr.fsf@earthlink.net>...
> Hyman: Is there a way to do that in C++?  Can you publicly inhterit from
> ColorableType and privately inherit from ColorableAdapterType?

Yes. I could have said

struct MyObject : private ColorableAdapter, private ResizableAdapter,
                  public virtual Colorable, public virtual Resizable
{ };

The interface methods all have a "unique final overrider" (in the
language of the C++ standard) so there is no ambiguity.

RE: Should MI be supported (was: Can MI be supported?)

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Matthew Heaney [mailto:matthewjheaney@earthlink.net]
...
| 
| In my experience multiple views are more useful than mixins, but YMMV.
| 
OK, it depends probably on design habits.

To translate Hyman example, did you use multiple views to stick with his
code, or because it's your "natural" choice?

-- 
Lionel Draghi

Re: Should MI be supported (was: Can MI be supported?)

[Matthew Heaney]

Lionel.DRAGHI@fr.thalesgroup.com writes:

> | -----Message d'origine-----
> | De: Matthew Heaney [mailto:matthewjheaney@earthlink.net]
> ...
> | 
> | In my experience multiple views are more useful than mixins, but YMMV.
> | 
> OK, it depends probably on design habits.
> 
> To translate Hyman example, did you use multiple views to stick with
> his code, or because it's your "natural" choice?

Both.  The multiple views code is exactly the code a C++ compiler would
generate for you.

Bob Eachus showed how to use generic mixins to translate Hyman's example
into Ada95, but the classes in the C++ example didn't strike me as being
proper "mixin" classes.  Usually it's pretty obvious when a class is a
mixin.

So can you use generic mixins to effect MI in Ada95?  Probably, yes.
Did I think Bob's translation was very natural?  Not really, no.

Re: Should MI be supported (was: Can MI be supported?)

[Robert I. Eachus]

Matthew Heaney wrote:

> Bob Eachus showed how to use generic mixins to translate Hyman's example
> into Ada95, but the classes in the C++ example didn't strike me as being
> proper "mixin" classes.  Usually it's pretty obvious when a class is a
> mixin.
> 
> So can you use generic mixins to effect MI in Ada95?  Probably, yes.
> Did I think Bob's translation was very natural?  Not really, no.

I guess we just have to agree to disagree on this.  I personally find 
the mixin idiom to be more natural than the view conversion approach. 
But Ada allows both, and in fact several other ways to code the same 
example, and we are talking about adding one more.

But this is how it should be.  Ada should allow you to express a model 
using whatever patterns are most appropriate.  If we disagree on which 
patterns to use, well that is a style issue, not something where there 
is a definite right or wrong.

Of course, the other discussion in this thread is one of right and 
wrong.  If you insist on "true" isa multiple inheritance, it has to be 
inconsistant.

For those who haven't studied such fun Theory of Computation topics as 
G�del's Proof, the Halting problem, and Post's correspondence problem, 
If you have one inconsistant axiom you can prove anything. G�del's Proof 
basically says that any programming language must be either incomplete 
or inconsistant. Problems like the Halting problem and Post's 
correspondence problem cannot be solved in general in any consistant 
language. Ada is incomplete, and it will stay that way, thank you very much.

-- 
                                           Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Should MI be supported (was: Can MI be supported?)

[Matthew Heaney]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> I guess we just have to agree to disagree on this.  I personally find
> the mixin idiom to be more natural than the view conversion
> approach. But Ada allows both, and in fact several other ways to code
> the same example, and we are talking about adding one more.

Well, there you go.  I much prefer access discriminants (I've sort of
abandoned the generic mixin approach -- too clunky for my taste), but to
each his own, as they say!

Re: Should MI be supported (was: Can MI be supported?)

[Lutz Donnerhacke]

* Robert I. Eachus wrote:
> I guess we just have to agree to disagree on this.  I personally find
> the mixin idiom to be more natural than the view conversion approach.

So do I.

> But Ada allows both, and in fact several other ways to code the same
> example, and we are talking about adding one more.

No. The discussion is about adding a high level abstraction which can be
implemented in any way.

> But this is how it should be.  Ada should allow you to express a model
> using whatever patterns are most appropriate.  If we disagree on which
> patterns to use, well that is a style issue, not something where there
> is a definite right or wrong.

Patterns or idioms usually point to a hole in the abstraction level of the
language.

> G�del's Proof basically says that any programming language must be either
> incomplete or inconsistant.

https://www.iks-jena.de/mitarb/lutz/usenet/Fachbegriffe.der.Informatik.html#293

  Halting Problem
     After proofing the impossibility of the general case, the programmer
     denies to implement any possible solution for important, ordinary cases.

Re: Should MI be supported (was: Can MI be supported?)

[Robert I. Eachus]

Lutz Donnerhacke wrote:

>   Halting Problem
>      After proofing the impossibility of the general case, the programmer
>      denies to implement any possible solution for important, ordinary cases.
> 

Ah, but good language designers choose between an incomplete language 
and an inconsistant one.  (Unfortunately the default for poor language 
designers is to choose inconsistancy.)

-- 
                                           Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a few minutes.  One thing he'd learned from 
Operation Beatrix: This field work wasn't for him. --from Red Rabbit by 
Tom Clancy.

Should MI be supported (was: Can MI be supported?)

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Robert I. Eachus [mailto:rieachus@attbi.com]
...
| 
| I don't know that I would call it "has a" but that is exactly what 
| mix-ins do.  But I have wondered whether we got mix-ins too 
| right in Ada 
| 95.  I just saw a post by Matt Heaney on access discriminants.  There 
| are some roles for which the mix-in needs access to the whole object, 
| and his particular example (persistant types) is one of them. 
|  But for 
| most roles where a role only needs access to its own state variables, 
| mix-ins do the job nicely and much more elegantly than access 
| discriminants.  

I agree with this point. 

By applying in my current project, the rule :
- if "Is A" then -> inheritance,
- if "Has some characteristics" then -> mixin,
then :
We use simple inheritance, 
We use mixin (and never run into case where mix-in needs to access the
whole),
We didn't use multiple views (but this is possibly due to design pratices), 
And, for now, i never encounter a "true" case of MI (there is more than half
a million Ada lines).

Thats why i think Ada 95 was well designed, by addressing the most common
needs : simple inheritance and mixins.
Mutiple views idiom translate awkwardly in current Ada, but who cares? It's
not useful enough to add some new cleaner syntax to the language for now.
The important thing is that there is at least an idiom.

I think interface inheritance may be a useful improvement for Ada 0Y, but
some other MI syntax will not meet an essential expectation.


-- 
Lionel Draghi

Re: Should MI be supported (was: Can MI be supported?)

[Matthew Heaney]

Lionel.DRAGHI@fr.thalesgroup.com writes:

> We use simple inheritance. We use mixin (and never run into case where
> mix-in needs to access the whole), We didn't use multiple views (but
> this is possibly due to design pratices). And, for now, I have never
> encountered a "true" case of MI (there is more than half a million Ada
> lines).

In my experience multiple views are more useful than mixins, but YMMV.


> Thats why i think Ada 95 was well designed, by addressing the most common
> needs : simple inheritance and mixins.
> Mutiple views idiom translate awkwardly in current Ada, but who cares? It's
> not useful enough to add some new cleaner syntax to the language for now.
> The important thing is that there is at least an idiom.

I disagree with both of your statements that the "syntax is awkward" and
that multiple views aren't "useful enough," but agree that it does get
the job done.  (I like the multiple views idiom, and I don't think it
gets used enough because many programmers don't really understand it, or
how to do it.)

Re: Should MI be supported (was: Can MI be supported?)

[Mário Amado Alves]

Lionel wrote: "... i never encounter a "true" case of MI ..."

Controlled streams. Controlled storage pools. Don't you find these
"true"? How do you solve it? Compare

  type Controlled_Stream is new Root_Stream_Type with Controlled;