danielgutson@hotmail.com (danielgutson@hotmail.com) wrote
> Problem:
>  Given a set of classes, find a way to avoid inheriting them
> multiplely.
> Motivation:
>  The idea is to provide some 'exclusiveness' mechanism for avoiding
> [i.e. library users] to misuse a design; a way of saying "you can
> inherit from this XOR from this", or "you can implement only one of
> these classes in one implementation".

// Untested

struct ExclusiveImpl {
#if DEBUG
    ExclusiveImpl() : Constructed(false) {}
    void exclusive() { assert(!Constructed); Constructed=true; }
private:
    bool Constructed;
#else
    ExclusiveImpl() {}
    void exclusive() {}
#endif
};
class Exclusive1 : virtual public ExclusiveImpl {
    Exclusive1() { exclusive(); }
};

Usage:
    class Human   : public Exclusive1 {};
    class Angel   : public Exclusive1 {};
    class Daniel  : public Human {};               // Okay
    class Gabriel : public Angel {};               // Okay
    class Mutant  : public Human, public Angel {}; // Asserts if constructed

Constructing a Mutant should assert.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

rmaddox@isicns.com (Randy Maddox) wrote in message news:<8c8b368d.0302060634.14853860@posting.google.com>...
> hyrosen@mail.com (Hyman Rosen) wrote in message news:<1044476930.953094@master.nyc.kbcfp.com>...
> > Randy Maddox wrote:
> OTOH, perhaps that might also be perceived as:  If there were NO
> compelling argument for "final", the thread would have been much
> shorter.  Or even:  If there were little interest and few arguments to
> be made, the thread would have been much shorter.
>
> IMHO, the length of the thread is testament to both the level of
> interest and the number of points to be made.

Perhaps some metrics could be more meaningfull, but I agree that
thread_length is not a goo metric. (maybe
thread_length/number_of_posters).

Anyway, the interesting analysis could be:

 Nowadays, a code might be the implementation of more than one design.
Let's say, if we denote by "Design -> Code" the Code that implements
Design,
we might have
   D1 -> C  and D2 -> C.
Sometimes, we have only the code, and must enhance it designing a
piece of code that **should** rely on the original design (i.e. by
following its assumptions).
But many of those times we don't have the original design (mostly
happens).
Then, we must 'deduce' (kind of reverse eng.) the design from the
code.
Given our 'deduced' design, we add our design and then our
enhancement.
   D -> C ~> D' -> C'
denoting by '~>' the 'deduction' (or inference) process.
Such process is quite ambiguos if many D1, ... Dn are possible
designs, that is
  D1 -> C,  ..., Dn -> C.

The idea of these kind of proposals is to minimize such ambiguities,
and strongize the '~>' part (as well as self-documenting the design
assumptions into the code), trying to approximate D' to D  (the
'deduced design' to the original design).

 Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message news:<1044476930.953094@master.nyc.kbcfp.com>...
> Randy Maddox wrote:
> > I believe that if you refer back to that "final" thread...   Perhaps
> > you should take another look instead of just dismissing all of those
> > reasons as mere "hand waving".
>
> I went back and took a look, and saw that the thread was 416 messages
> long. If there was a compelling argument for "final", the thread would
> have been much shorter.
>
>

OTOH, perhaps that might also be perceived as:  If there were NO
compelling argument for "final", the thread would have been much
shorter.  Or even:  If there were little interest and few arguments to
be made, the thread would have been much shorter.

IMHO, the length of the thread is testament to both the level of
interest and the number of points to be made.

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message news:<1Vk%9.5977$WQ2.3447@nwrddc02.gnilink.net>...
> danielgutson@hotmail.com wrote:
> >   I'd like again your feedback about a proposal.
> > Problem:
> >  Given a set of classes, find a way to avoid inheriting them multiplely.
>
> I think people should stop trying to stop other people from doing stuff.

This is useful for:

* self-documentation: you tell the user the intention of the design:
    - showing that those classes sharing the same 'equivalence-class'
are unique in their 'kind' (in the example, 'humanity' and 'angelity'
are unique in terms of 'entiticity', and I hope you don't care about
my English manipulation :) )
* avoiding errors: you protect your system ensuring that the user will
use your library properly because of errors.

 Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message news:<1Vk%9.5977$WQ2.3447@nwrddc02.gnilink.net>...
> danielgutson@hotmail.com wrote:
> >   I'd like again your feedback about a proposal.
> > Problem:
> >  Given a set of classes, find a way to avoid inheriting them multiplely.
>
> I think people should stop trying to stop other people from doing stuff.
>

I, on the other hand, think people should stop trying to prevent class
designers from clearly and fully expressing their intent and having
the compiler provide some support to ensure that intent is not
violated.  If there is an issue with multiply inheriting from a class
due to design assumptions made in implementing that class, then this
constraint should be expressible in C++ and enforceable by the
compiler.  It is simply not the case that every single class ever
designed should be considered to be suitable for further derivation or
for multiple derivation.  The designer of such a class currently has
no support from C++ to enforce those type of constraints, and relying
on documentation is always going to be a weaker reed than language
support.

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Randy Maddox wrote:
> I, on the other hand, think people should stop trying to prevent class
> designers from clearly and fully expressing their intent and having
> the compiler provide some support to ensure that intent is not
> violated.

I've yet to see some clearly and fully express their intent
in English when it comes to explaining why they want to
impose these limits. There's a lot of hand waving involved,
usually about something that "might be needed". This is the
same sort of thing that came up in the "final" thread.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> It completely provides functionality of your "exclusive"
> Just do
> class A{};
> class B1: restrict A {...};
> class B2: restrict A {...};
> class C: public B1, B2 {}; // error

This has a different meaning, but answers the question I posted in the
original message.

The keyword in the base class list, has an 'egoist' meaning, saying "I
want to be the sole heir of this class in my inheritance graph."
Putting the keyword at the class level, is a banner provided by the
class saying "I AM an exclusive [equivalence] class. All my heirs will
be unique in their inheritance graphs".
This has the advantage to show the design intention from the begining,
and is quite clear during a top-bottom class analysis, as showed in
the following example:

exclusive struct Color { virtual int colorId()=0; };
exclusive struct Age { virtual int strength()=0; virtual int
wisdom()=0; };
exclusive struct Team { ... };

class Red : Color{...}; class Green : Color{...}; class Blue : Color
{...};
class Young : Age {...}; class Grownup : Age {...}; class Ancient :
Age{...};
class Human : Team {...}; class Elf: Team {...}; class Dwarf : Team
{...};

// impl.
class JohnTheMan : Red, Young, Human {...};
class PeterTheDwarf: Green, Dwarf, Grownup { ... };
class NimrodTheElf : Blue, Elf, Ancient { ... };

Anyway, I think both cases are complementary, and should be only one
keyword, whichever it is chosen.

 Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message news:<1044390190.591579@master.nyc.kbcfp.com>...
> Randy Maddox wrote:
> > I, on the other hand, think people should stop trying to prevent class
> > designers from clearly and fully expressing their intent and having
> > the compiler provide some support to ensure that intent is not
> > violated.
>
> I've yet to see some clearly and fully express their intent
> in English when it comes to explaining why they want to
> impose these limits. There's a lot of hand waving involved,
> usually about something that "might be needed". This is the
> same sort of thing that came up in the "final" thread.
>

I believe that if you refer back to that "final" thread you will see
that there were several very good reasons presented for why and how a
class might be implemented in such a way that dervivation from that
class is not a good idea, and further that some of those specific
reasons were presented by well-known and respected folks whose
thoughts certainly carry more weight than my humble opinions.  Perhaps
you should take another look instead of just dismissing all of those
reasons as mere "hand waving".

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Randy Maddox wrote:
> I believe that if you refer back to that "final" thread...   Perhaps
> you should take another look instead of just dismissing all of those
> reasons as mere "hand waving".

I went back and took a look, and saw that the thread was 416 messages
long. If there was a compelling argument for "final", the thread would
have been much shorter.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Newsgroupers:

  I'd like again your feedback about a proposal.

Problem:
 Given a set of classes, find a way to avoid inheriting them
multiplely.

Example: suppose something cannot be at the same time a human nor an
angel.
 Entity{};
  Human: Entity{};
  Angel: Entity{};

 Daniel: Human{};
 Gabriel: Angel{};

 The problem definition is: how to ensure that nobody will inherit
from both Human and Angel?

Motivation:
 The idea is to provide some 'exclusiveness' mechanism for avoiding
[i.e. library users] to misuse a design; a way of saying "you can
inherit from this XOR from this", or "you can implement only one of
these classes in one implementation".

Proposed solution:
 Provide 'exclusive equivalence-classes'  (classes in the algebraic
sense, given an equivalence relationship).
 <Classes belonging to same equivalence-class cannot be parent classes
of the same subclass>

How:
 Define a class as equivalence-class, with a class-level declaration
attribute: 'exclusive' (let's think later for a good keyword, new or
existent).

 Property: a class can belong to more than one equivalence-class, by
inheriting from them.

Supposing the 'exclusive' keyword is used, the above example would be:

exclusive class Entity{};
class Human: public Entity{};
class Angel: public Entity{};

In practical terms, 'exclusive' forbids virtual inheritance.
(no one can do
class Hybrid: Human, Angel{}; )

Another example:
 If you want to force exclussion between
      JavaProgrammer, CPPProgrammer
but still want to allow
      CPPProgrammer, HaskelProgrammer
and
      JavaProgrammer, HaskelProgrammer

you can declare:

class Programmer{}  // for beauty purposes only
exclusive class Exclusion1{};
class HaskelProgrammer : virtual Programmer {};
class CPPProgrammer : virtual Programmer, Exclusion1 {};
class JavaProgrammer : virtual Programmer, Exclusion1 {};

Compatibility:
 Lays in finding a keyword. If no already existent is good, I propose:
exclusive, single, at the left of 'class',
or a character (for example '~' ) prefixing the class name.

If anybody knows an existent way of solving this problem, please let
me know. I could not find any.

Open issue:
  *should 'exclusive' (or the chosen keyword) be available also in the
base classes list context too?
(example:
class CPPProgrammer : exclusive Programmer, Exclusion1 {};
)
(Additionally to the class-level attribute).

Thanks again!

  Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message

> Problem:
>  Given a set of classes, find a way to avoid inheriting them
> multiplely.
>

Daniel, try to look at my parallel thread about "virtual restrict"
inheritance.  The intent of my proposal was to solve absolutely
different problem but it seems that it solves yours as well..

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dlagno@mail.nnov.ru (Denis Lagno) wrote in message news:<5a0f3464.0302021920.1ee4cac8@posting.google.com>...
> danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message
>
> > Problem:
> >  Given a set of classes, find a way to avoid inheriting them
> > multiplely.
> >
>
> Daniel, try to look at my parallel thread about "virtual restrict"
> inheritance.  The intent of my proposal was to solve absolutely
> different problem but it seems that it solves yours as well..

Hi Denis,

 Well, considering I did not fully understand your proposal :) I think
there are some differences.

1- The problem I'm trying to solve includes non-virtual inheritances
(the 'fork' or 'Y'-shaped inheritance)
(i.e. avoiding

   class A{};
   class B1: A{}; class B2: A{};
   class C : B1, B2 {};
)

2- Your 'restrict' keyword applies to the base-class list, while
'exclusive' (or the candidate keyword) would apply at the
class-definition-level
(in the above example:
   exclusive class A{};
   class B1: A{}; class B2: A{};
   class C : B1, B2 {}; // error
)

I hope I understood your prop. enough for saying this, but I'm not
sure :)
Thanks!

  Daniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

danielgutson@hotmail.com wrote:
>   I'd like again your feedback about a proposal.
> Problem:
>  Given a set of classes, find a way to avoid inheriting them multiplely.

I think people should stop trying to stop other people from doing stuff.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message
> 1- The problem I'm trying to solve includes non-virtual inheritances
> (the 'fork' or 'Y'-shaped inheritance)
> (i.e. avoiding
>
>    class A{};
>    class B1: A{}; class B2: A{};
>    class C : B1, B2 {};
> )
>
> 2- Your 'restrict' keyword applies to the base-class list, while
> 'exclusive' (or the candidate keyword) would apply at the
> class-definition-level
> (in the above example:
>    exclusive class A{};
>    class B1: A{}; class B2: A{};
>    class C : B1, B2 {}; // error
> )

I have already posted correction to my post, but it travels too long.
"restrict" keyword can be applied to any type of inheritance.  It is
just modifier  of inheritance.
It completely provides functionality of your "exclusive"
Just do
class A{};
class B1: restrict A {...};
class B2: restrict A {...};
class C: public B1, B2 {}; // error

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]