Perhaps talking about this as "Multiple inheritance with a common base
(diamond relationships)" might avoid the terminology issue.
The main point of this section is to explain that multiple inheritance
from a common name does not pose a conflict if the name comes from a
common base type (i.e. there is a diamond relationship between the
derived type and the common base type).
In the case of multiple specializations, there is a conflict since the
types are different; those comments are again reinforcing the fact that
different specializations are different types (so no "diamond
relationship" exists). So I agree that saying "there is no diamond
problem" is likely less clear than something like "there is no diamond
relationship with a common base type".
I think that it is useful to talk about "diamond relationships" or
similar since a very common question for people understanding a new MI
language is how the language handles diamond inheritance.
The Wikipedia description you quote seems to be pretty biased towards a
C++ understanding of implementation inheritance. "Diamond problems" are
really more general in the sense that they involve resolution of "unique
items". In C++ the "implementation overrides" are most problematic
(hence the Wikipedia focus), but in SV (or Java), general name
visibility is really the only issue as no multiple implementation
inheritance is possible.
Gord.
On 11/21/2011 4:25 AM, Bresticker, Shalom wrote:
> Hi, Brandon.
> It seems to me that you are using the term 'diamond problem'
> differently than other people.
> Wikipedia describes the diamond problem like this:
> In _object-oriented_ <http://en.wikipedia.org/wiki/Object-oriented>
> _programming languages_
> <http://en.wikipedia.org/wiki/Programming_language> with _multiple
> inheritance_ <http://en.wikipedia.org/wiki/Multiple_inheritance> and
> knowledge *organization*, the *diamond problem* is an ambiguity that
> arises when two _classes_
> <http://en.wikipedia.org/wiki/Class_%28computer_science%29> B and C
> _inherit_
> <http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29> from
> A, and class D inherits from both B and C. If a _method_
> <http://en.wikipedia.org/wiki/Method_%28computer_science%29> in D
> calls a method defined in A (and does not _override_
> <http://en.wikipedia.org/wiki/Method_overriding_%28programming%29> the
> method), and B and C have overridden that method _*differently*_, then
> from which class does it inherit: B, or C?
> The emphasis on "differently" is mine.
> You seem to be using the term in an opposite, and confusing, way.
> If the same interface class is inherited or implemented more than
> once, there is no conflict, but you are calling it a 'problem'.
> If the same interface class is specialized in two different ways, then
> a conflict is created, but you say that this is not a diamond problem.
> I think this case is much closer to the Wikipedia definition of
> diamond problem.
> Do you have to use the term 'diamond problem' at all?
> Shalom
> _____________________________________________
> *From:* Tipp, Brandon P
> *Sent:* Wednesday, November 16, 2011 6:47 PM
> *To:* Bresticker, Shalom; Alsop, Thomas R
> *Cc:* Neil Korpusik; Tipp, Brandon P
> *Subject:* RE: Mantis 1356 v16 - "inherit"
> How about this:
> The /diamond problem/ occurs if an interface class is implemented by
> the same class or inherited by the same interface class in multiple
> ways. The diamond problem shall be solved by merging only one copy of
> any conflicting symbols so as to never result in a name conflict. For
> example:
> *interface class* IntfBase;
> *parameter *SIZE = 64;
> *endclass*
> *interface class* IntfExt1 *extends* IntfBase;
> *pure* *virtual function bit* funcExt1();
> *endclass*
> *interface class* IntfExt2 *extends* IntfBase;
> *pure* *virtual function bit* funcExt2();
> *endclass*
> *interface class* IntfExt3 *extends* IntfExt1, IntfExt2;
> *endclass*
> In the above example, the class IntfExt3 inherits the parameter SIZE
> from IntfExt1 and IntfExt2. Since these parameters originate from the
> same interface class, IntfBase, only one copy of SIZE shall be
> inherited into IntfExt3 so it shall not be considered a conflict.
> -Brandon
> _____________________________________________
> *From:* Bresticker, Shalom
> *Sent:* Wednesday, November 16, 2011 9:31 AM
> *To:* Tipp, Brandon P; Alsop, Thomas R
> *Cc:* Neil Korpusik
> *Subject:* RE: Mantis 1356 v16 - "inherit"
> Well, it's not solved by the tool. Rather, the LRM defines a resolution.
> Shalom
> _____________________________________________
> *From:* Tipp, Brandon P
> *Sent:* Wednesday, November 16, 2011 6:29 PM
> *To:* Bresticker, Shalom; Alsop, Thomas R
> *Cc:* Neil Korpusik; Tipp, Brandon P
> *Subject:* RE: Mantis 1356 v16 - "inherit"
> I was searching for a known computer science term synonym for "diamond
> inheritance" and came up with the "diamond problem". It is still a
> problem, it's just solved by the tool rather than solved with name
> conflict resolution in the code.
> The /diamond problem/ occurs if an interface class is implemented by
> the same class or inherited by the same interface class in multiple
> ways. The diamond problem shall be solved by tools so as to never
> result in a name conflict. For example:
> _____________________________________________
> *From:* Bresticker, Shalom
> *Sent:* Wednesday, November 16, 2011 2:23 AM
> *To:* Tipp, Brandon P; Alsop, Thomas R
> *Cc:* Neil Korpusik
> *Subject:* RE: Mantis 1356 v16 - "inherit"
> I don't like this wording. It seems contradictory. On the one hand, it
> calls it a "problem". On the other hand, it says there is no conflict,
> i.e., no problem.
> Regards,
> Shalom
> _____________________________________________
> 8.25.6.3 says,
> Diamond inheritance occurs if the same interface class is inherited by
> the same class or interface class in multiple ways.
> Yet we say that a class does not "inherit" an interface class.
> /*[Tipp, Brandon P] I've seen some reference to this as "the diamond
> problem". I'm rewording it as follows:*/
> *8.25.6.3 Diamond problem*
> The /diamond problem/ occurs if an interface class is implemented by
> the same class or inherited by the same interface class in multiple
> ways. The diamond problem never causes a name conflict. For example:
> ...
> (I also changed the later mention of "diamond inheritance" to "diamond
> problem").
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
-- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Nov 21 07:47:41 2011
This archive was generated by hypermail 2.1.8 : Mon Nov 21 2011 - 07:47:45 PST