Bill Baxter wrote:

>> However, I understand your point. If a base class is changed, and you have no source-access to it, you still don't want to entirely break your subclass away from it. Maybe another type of relationship should be formally introduced for such situations. 'Is-kinda-like', or 'is-mutation-of' or something, which would allow suppressing parts of the public interface.
> 
> Isn't that what interfaces and object composition are for?
> If what you have isn't is-A, then like you said inheritance is probably
> not the relationship you're after.  Create a
> ThingsPeopleHaveIrrationalAttatchmentsTo interface and have both Pet and
> Aibo implement it.  Aibo might implement it internally using a Pet member.

Object composition would indicate a 'has-a' relationship. Both normal inheritance AND interfaces indicate 'is-a' relationships.

I like your solution. But if an 'is-kinda-like' relationship could formally be created, that would be even better.

If Aibo is-kinda-like Pet (with the food-interface removed), then:

* You could not pass an Aibo to a function that asks for a Pet. You
would simply use Pet for the implementation only.
* Maybe a smart compiler could recognize that the private member 'food'
is not used by any inherited public function and disregard it when
allocating memory.
* Code would become more readable and maintainable.

There could be other advantages.

-- 
Michiel

Kevin Bealer wrote:
> I've often thought that in C++ I could achieve neat results by copying the vector,
> string, and map classes and adding my own functionality, but there is the
> annoyance of duplicating the half dozen or so string constructors.  The simplest
> c++ syntax I have found is this (not tested):
> 
> class MyString : string {
> public:
>     template<A>   MyString(A x) : string(x) {}
>     template<A,B>  MyString(A x, B y) : string(x,y) {}
>     template<A,B,C> MyString(A x, B y, C z) : string(x,y,z) {}
> };
[snip]

This is where I think well designed mixins really start showing their power.  The problem in C++ is that the base classes are not written in the mixin design pattern, probably because its yet another level of C++ complexity to add.  In D mixins are easy, so theres is really no excuse.

Having said that I don't think they solve this problem entirely.

=Joel

janderson wrote:
> Kevin Bealer wrote:
>> I've often thought that in C++ I could achieve neat results by copying the vector,
>> string, and map classes and adding my own functionality, but there is the
>> annoyance of duplicating the half dozen or so string constructors.  The simplest
>> c++ syntax I have found is this (not tested):
>>
>> class MyString : string {
>> public:
>>     template<A>   MyString(A x) : string(x) {}
>>     template<A,B>  MyString(A x, B y) : string(x,y) {}
>>     template<A,B,C> MyString(A x, B y, C z) : string(x,y,z) {}
>> };
> [snip]
> 
> This is where I think well designed mixins really start showing their power.  The problem in C++ is that the base classes are not written in the mixin design pattern, probably because its yet another level of C++ complexity to add.  In D mixins are easy, so theres is really no excuse.
> 
> Having said that I don't think they solve this problem entirely.
> 
> =Joel

I should clarify, I'm talking about the template mixins, not the ones that take a string.

-Joel

On Fri, 02 Mar 2007 09:26:21 +0200, janderson <askme@me.com> wrote:

> janderson wrote:
>> Kevin Bealer wrote:
>>> I've often thought that in C++ I could achieve neat results by copying the vector,
>>> string, and map classes and adding my own functionality, but there is the
>>> annoyance of duplicating the half dozen or so string constructors.  The simplest
>>> c++ syntax I have found is this (not tested):
>>>
>>> class MyString : string {
>>> public:
>>>     template<A>   MyString(A x) : string(x) {}
>>>     template<A,B>  MyString(A x, B y) : string(x,y) {}
>>>     template<A,B,C> MyString(A x, B y, C z) : string(x,y,z) {}
>>> };
>> [snip]
>>  This is where I think well designed mixins really start showing their power.  The problem in C++ is that the base classes are not written in the mixin design pattern, probably because its yet another level of C++ complexity to add.  In D mixins are easy, so theres is really no excuse.
>>  Having said that I don't think they solve this problem entirely.
>>  =Joel
>
> I should clarify, I'm talking about the template mixins, not the ones that take a string.
>
> -Joel

Yes, mixins are useful in some situation, as you said. However, if I need to (quickly) change the behavior of a class by overriding a function or two, mixins don't help: I have to write (usually) the constructors anyway. If I'm writing a library, I could provide mixins for easier inheritance. That's just a lot of unnecessary work and redundant code, and they make the library harder to maintain.

On Mon, 26 Feb 2007 15:31:29 +0200, Kristian Kilpi <kjkilpi@gmail.com> wrote:
>
> I think class inheritance is a bit(?) tedious sometimes (that is, unnecessarily tedious).
> (I leave interfaces out of this discussion.) 'Problems', IMHO, with it are:
>
> 1) You cannot inherit constructors.
>
> 2) A function will hide inherited functions having the same name.
>
> 3) The syntax for calling a super function of the base class is redundant and (could be) tedious.
>
[snip]
> What about the case 3? Well, lets have the following member function:
>
>    foo(int value, int x, int y, bool is_clipped, bool is_inverted, string label = null) {
>      ...
>
>      super.foo(value, x, y, is_clipped, is_inverted, label);
>    }
>
> It would be nice to have the following possible:
>
>    foo(int value, int x, int y, bool is_clipped, bool is_inverted, string label = null) {
>      ...
>
>      superfunc(..);  //equals to 'super.foo(value, x, y, is_clipped, is_inverted, label);'
>    }
>
> 'superfunc(..)' (or 'superfunc($)' or something) is non-redundant, easy to read, and
> trivial to maintain (because no maintenance is needed! :) ).
>
> You can of course define the arguments by yourself if needed:
>
>    superfunc(value + 1, x, y, false, is_inverted);


What, nobody voted for the case 3? I'm stunned. ;)

To me having 'superfunc' would be about as nice as having 'this' for ctors/dtors...
Lets put it this way: how many C++ person would switch back to use the class name in
the construtors and destructors instead of 'this'?