Talk:Virtual inheritance

From Wikipedia, the free encyclopedia

You have new messages (last change).
This article is supported by the Wikipedia:WikiProject C++. Please visit the project page for more details on the project.


virtual inheritance relates to the properties of class inheritance given single but more commonly multiple ineritance heirarchies. Virtual inheritance is not merely a resolution issue (in the classic sense of the word resolution) - since the compiler under multiple inheritance cannot determine the location of the virtual base within the heirarchy at compile time.

At run time the executable will refer to the vtable to find the location of the 'virtual instance' within the heirarchy given a dynamic cast across that heirarcy or a call (virtual or otherwise) on a method of the virtually instantiated class or other access to a resource of the class object. This is similar to the mechanism used to find the dispatch address of a virtually overidden method at runtime. This however represents the limit of any similarity between polymorphic behaviour and a virtually inherited class. Herein also lies the reason for confusion over the semantic term ('virtual') which was often chosen for both polymorphic behaviour and virtual inheritance. In this case it was because the compiler writers understood that the bevaviour at the level of implementation functionality was similar.

class X: public virtual Y { } represents virtual inheritance in Java and c++.

The same concept applies to single inheritance languages except that the idiom is less meaningful since the compiler will know given any reference or pointer to an object where that class exists in the heirarchy. virtual inheritance however is typically understood to refer to the same mechanism irrespective of whether single inheritance (Java) or multiple inheritance (c++) is being considered.


it does not make sense to attempt to ascribe other meanings to a commonly used and understood term and this is why the article is disupted

Thank you, anonymous user, for adding more fuel to the fire. Still haven't seen any evidence from Shawn. I like to assume good faith, but I feel that a disputed article should be changed to the commonly held definition and then the appropriate changes made *after* Shawn can find evidence for his interpretation. That way we're not publicising what is generally agreed to be incorrect information (unless I'm mistaken, nobody at all has agreed with Shawn yet?) Give me a few weeks to have the time (end of year crunch), and I'll overhaul this page. --Mike Blackney 11:27, 21 October 2006 (UTC)
Mike,
I have replaced my article with the original version from May 2006. I'll put a section at the top (just below this) with the results of my ACM paper searches as well as some online links you can use for your version of Virtual Inheritance. I look forward to reviewing your version and comparing it to the papers I have from the ACM (please see the end of the Cleanup - Displute section below).
Shawnktalk—-Shawn wiki 02:57, 25 October 2006 (UTC)
Shawn, I applaud you for your academic integrity and fortitude on this one. For a while I've been disappointed with this page, but haven't bothered to change it. I am quite impressed that you worked so hard to prove your version of the definition and then, realizing you were wrong, correcting the page. This seems like an excellent example of how demanding citations can work very well. Thanks for all your hard work. —Ben FrantzDale 12:18, 25 October 2006 (UTC)


Ben, My pleasure (in spite of the pain :-). In a parting note - many scientists and engineers are gifted with the ability to see a domain ontology, taxonomy and its semantics 'ALL AT ONCE' as an integrated whole. I am one of those people. Several papers on the ACM site (as late as 2006) discuss the LACK OF a clear and fundamental definition of Object Oriented programming VIA THE EXISTENTIAL (fundamental) OO ontology, taxonomy and COHERENT SEMANTICS.
Although 'fellow' class employees and Sr. project leaders may use such terms as a matter of fact in day to day programming, this venue (WikiPedia) does not lend itself to such thinking (as noted, for example, by the 2006 'Quark' ACM paper mentioned elsewhere herein and the discussion intro above (..does not make sense to ascribe other meanings..).
Defining THE fundamental 'box' (as in 'thinking out of the box') for the OO paradigm is not possible in WikiPedia as such efforts are tagged as 'personal research' [assuming (1) a true fundamental model exists and (2) it is significantly different from the 'popular model' as defined in WikiPedia]. My original intent in the article was to define concepts relative to another Wikipedia article on the 'functional normalization' of multiple inheritance (in terms of 'virtual and implementation' inheritance and code elements). Without the correct 'box' to think in (coherent, correct, closed - ontology, taxonomy and semantics), however, discussions of SQL database normalization and OO programming normalization (as the same simple phenomena with fundamentally the same semantics) are futile (actually just very wasteful of time and energy).
I (personally) find that WikiPedia only perpetuates a flawed 'IN THE BOX' way of looking at OO programming and thus perpetuates an essentially flawed and incorrect model:-) I do however, deeply appreciate (and enjoy :-) the professional attitude shown by the WikiPedia community (such as yourself) in this SOCIAL PATH to documenting current knowledge. I regret that I do not find writing WikiPedia articles rewarding for this reason and will not be doing any more work in this arena.
As a Sr. Engineer I understand (and appreciate) the pragmatism of just getting the job done (and working well with others :-) without being religious or rigorous (as in reference material of this kind). I hope in the future that references in all WikiPedia articles can have links that lead 'outward' to reference sources of a more fundamental nature. Thanks, again, for your professionalism. I think you represent the essence of what makes a community like Wikipedia so successful :-)
Shawnktalk—-Shawn wiki 16:38, 14 November 2006 (UTC)

Contents

[edit] Cleanup - Dispute

Here you go, Shawn. I've made an account so now you know whose name to type when you're really angry. This article is disputed. Not only by me, but also previously by Ben and another anonymous (maybe more as well - the discussion page needs archiving badly). I will be adding the tag because I still dispute it.

As an answer to your challenge: I don't need to give any quotes at all. That's not how this whole encyclopedia thing works. Facts aren't correct until proven incorrect. I don't need to prove it's not accurate and correct. The person writing the article needs to prove that it is accurate and correct. I don't feel you've done that. Your references are all offline. Give some online references that state that Virtual Methods have anything to do with Virtual Inheritance, or I will request arbitration for this article. Cite your content, and cite it with online content that is verifiable and even remotely relevant, or quit removing the cleanup tag and let people with decent communication skills have a go. --Mike Blackney 06:48, 6 September 2006 (UTC)

Thanks for making a profile. I removed the clean up tag because you're premise is that the article is incorrect in its definition of a language independent meaning of virutal inheritance. So I would like to discuss the points of dispute as a dispute prior to a simple 'cleanup'. It will also help the arbitrators to see clearly the basis of your dispute and my response prior to the actual arbitration.
Please feel free to call for arbitration.
Prior to your request for arbitration could you enumerate your points of dispute? I belive that you are repeating the points in the earlier discussions.
As to the online/offline reference. Virutal inheritance, as defined in the article, was around long before the Internet. The historical record (in books) is VERY relevant to software patent work. The quotes should be enough to 'prove' the validity of definition as defined. You can not use more 'online' sources to take away what was written in the 1980s regarding the history of object-oriented languages development in the 1960s/1970s by the founders (of OOP).
I specifically put in the last line of the article of the quote that shows that 'virtual specification' is the basis virtual inheritance phenomena. The 1993 reference books (again, prior to the online world) also prove the language independent nature of the definition.
To discount the books as a valid source of research and a valid source of proff is not valid (with all due respect). Patent work commonly does this and ALL research must do this unless the books are transcibed and made available online.
Furthermore, the ACM external link is provided. I highly recommend you do a search there for virtual inheritance and review some of the earlier papers (in PDF file format).

Shawnktalk—-24.12.95.75 14:35, 6 September 2006 (UTC)

1. This article is about "Virtual Inheritance". I do not believe that the article, as you have written it, restricts itself to that topic. I feel you have tried to make a comprehensive account of all computer-related information that even remotely involves the word "virtual".
2. This article references a number of somewhat related resources, but nothing that states outright, online and verifiable, what you have stated in this article. This makes the VI article look suspiciously like Original Research, which would be valid if placed on your own website, but does not represent the views of the community and is thus entirely out of place here on Wikipedia.
3. The ACM website you have provided as an external link is useless. Their Search page results in "Object not found" errors. Nonetheless if their site honestly contains the information you claim it to, please provide a link to the actual PDF, and perhaps a description of what we can find there.
4. The 'quotes' are generally irrelevant. Please remove them or explain why they relate to Virtual Inheritance, not as you understand it, but as it is seen by the community. If you wish to include quotations from third parties explaining how these quotes relate to Virtual Inheritance, please do. Otherwise, you're drawing inferences and conducting original research.
Please don't only provide offline references. If you want C# topics to be in here, I know that you're not going to use any old resources from the 60's. C# isn't that old. If you want this page to include information on the derivation of the Virtual Inheritance concept, please list anything online or you risk looking like this is original research, and that your References are simply placed there to discourage anybody challenging you.
5. You seem to understand Virtual Methods (virtual code elements) as fitting beneath the umbrella of Virtual Inheritance. I feel that virtual methods have nothing to do with virtual inheritance - that they have their place in articles on type polymorphism and abstract class inheritance.
6. The code examples are unnecessarily long and show nothing that couldn't be shown in concise code snippets. (For example, like the snippets that were in place before you began to bloat the article.)
7. Your original title for this section, "Cleanup Dispute - Finished Article," shows some of what is wrong with your attitude towards Wikipedia. The "Finished Article" bit: that's not how Wikipedia works. People will fix your mistakes and polish your article until it is a concise cluster of on-topic knowledge, there for easy absorption. There is no such thing as a "Finished Article". As times change, the topic may change. If not, language will change, and the information will be better conveyed in other language. It will be updated by those in the know forever, long after we are both dust.
Your actions make you look like a cyber-squatter. It seems that you have decided that this article is 'yours' and now you are trying to make it a universal reference on all topics that relate to the words "virtual" and "inheritance", all the while reverting any changes you feel to have interfered with the agenda you are pushing. That's not what Wikipedia is for. If somebody wants to find out what Virtual Inheritance is, and they come to this page, it would take literally hours to even come up with a basic summary. The topic is nowhere near as complex as you make it out to be, and that is the crux of my argument that this article needs cleanup.
How about this? If you still disagree, and I'm sure you do, we take this from *discussion* to the next stage before arbitration: a poll. If you can get any other experts who, like yourself, have a million years experience and wholeheartedly disagree with me then I applaud you. But I don't believe that will be the case. I feel that your bullying and reverting crosses the line of acceptable behaviour in this forum, and I believe that this is the exact reason why others who have tried to challenge the content of the article have given up - they didn't think it was worth the effort. I feel it is. --Mike Blackney 03:15, 7 September 2006 (UTC)
Also, a word on the Disputed tag: Please, please don't remove it. I have placed it there so that people will see that this article is disputed. Think of it this way: if your content is correct, you will benefit from more people seeing the page and coming here to back up your argument. And additionally, if you remove it you will begin to look even more like somebody who is far too precious of their work. Please don't be. It's here for the community, not for ourselves.
In addition, please read the Wikipedia:Article_size section. This article is mammoth, but it is also stylistically overbearing. I know the topic (arguably - you don't seem to agree on that) yet I can't read it. It would make a great thesis. I feel it makes an awful article. --Mike Blackney 03:32, 7 September 2006 (UTC)
I have no problem with the dispute tag. I clearly feel the article defines what virtual inheritance is. I strongly disagree on your bullying and squatting contentions. The 'crux' of your argument on clean up is fine by me as the primary objective is the correct defintion of virtual inheritance. I feel the first few paragraphs explain Virtual Inheritance concisely. The core points are simple (virtual code element, use context) and allow concise statements to be made comparing virtual inheritance in different languages. I feel as strongly as you do about an accurate definition of Virutal Inheritance and your point [1],[5] is the key basis of this dispute. Your points [2],[3],[4] regarding references can be worked on. The references in the article are valid.
By the way is your definition of Virtual inheritance the C++ Keyword definition (based on the C++ virtual keyword)?
Finally the definition of Virtual Inheritance should stand up to patent level work which is based on books and offline content. I won't remove the dispute tag. Are you recommending that the definition be a political voting process over historical prior work in the industry???
Shawnktalk—-Shawn wiki 05:45, 7 September 2006 (UTC)
Mike - and other interested parties - I'm am researching all online sources but especially the ACM papers (online but you need a membership). I have a 'heavy' time consuming 'real work' project that is extending my research time. I do want to get you the 'online' research sources so everyone can review them. Note that if the article is removed, pulled or redone that is OK by me (after I did my best effort :-). I think the need to have the 'classic' lanaguage virtual inheritance definition is critical to comparing C# interfaces and C++ abstract methods (different because of use context) and is vital to future compiler lanaguages. I respectfully disagree with some of your points which have been discussed elsewhere in the discussion (generate a PDF and do a word search in Adobe reader Version 7).
I am trying to complete the research (for online content - especially the ACM papers) this week and next. This way the arbitration board (God bless them) can make a qualified determination and allow/support you to pull the content and redefine the meaning or replace the whole article (or redo the content if you are better at communicating the meaning). Thanks for your input and I hope that your good point (about online verifiable sources) can be incorporated to compliment the current 'book/paper' sources (which are commonly found in the better College libraries (MIT, Stanford, Purdue, etc) but not readily available to many people such as yourself).
I hope the caliber of the article (relative to accuracy and complete coverage of subject) is good enough for 'initial software patent work' and not a 'popularity vote' (sorry for the polemic there). Anyway I find the discussion/dispute understandable because of the amount of 'junk' on the internet and look forward to arbitration and dispute resolution. Thanks again for your (and everyone elses) patience on this article. I (truly) look forward to finishing the 'verifable sources' research, puting in the links (in the referecnce section) and letting the rest of the world edit/remove/change/etc the article. I just hope the arbitration board will look at the need to discuss 'virtual inheritance' from a fundamental language independent aspect (as in the ACM papers over the history of computing going back to the 1960s) rather than the 'internet/google search/popularity' meaning.
Thanks to all for giving me a little more time to complete the 'online' reference sources.
Shawnktalk—-24.12.95.75 16:16, 17 September 2006 (UTC)
That's fine Shawn - take your time. I have also had a lot on my plate recently, so I've not been able to devote time to giving you a good response to your questions.
You asked if my definition of Virtual Inheritance was the C++ keyword definition. No, that's not what Virtual Inheritance is. The C++ virtual keyword has different meanings in different contexts. When placed before a class' function name, it specifies that the function is Virtual and should be dynamically linked using a vtable. This use of the virtual keyword has nothing to do with Virtual Inheritance. This use of the virtual keyword comes under Virtual functions and has no place in the VI article. Virtual Inheritance hierarchies can exist comfortably without any virtual functions at all. A Virtual Inheritance solution is implemented in terms of a vtable, but aside from this commonality otherwise has nothing to do with virtual methods. Likewise, whether a virtual method is abstract or not has nothing to do with Virtual Inheritance because Virtual Inheritance has nothing to do with Virtual Methods.
When used in a class declaration, e.g., class Ford : virtual public Car, it specifies that the Ford class will virtually inherit from the Car class. This is the only meaning for Virtual Inheritance in C++.
Virtual Inheritance is a relationship. It does not exist until a class (B) inherits virtually from another class (A). The class A becomes the virtual base class of B, yet we haven't changed A. Another class (C) could inherit from A using regular inheritance, and A would be a regular base class of C. Again, Virtual functions are irrelevant to this relationship.
As references for the above paragraphs I will cite the texts "Liberty's C++ Unleashed" (ISBN 0-672-31239-5), "Borland C++ Programmer's Guide" (ISBN 0-672-30923-8), "Thinking in C++ (Volume 2)" (ISBN 0-130-35313-2; Available online here); and the online references: C++ FAQ Lite, A short DevX article on Virtual Inheritance, A PHC Article on memory layouts for Virtual Inheritance. All of these resources were chosen because they were right there next to my desk computer or because they were the first links from a VI Google search (besides your VI article, which is the only one I've found that isn't in concordance with my understanding.)
For Virtual Inheritance with respect to C++, this relationship between classes is the only meaning. That's part of the reason why I find some of the quotes and your resources ambiguous in relevance. It's not enough that they contain the word Virtual. They must also contain the phrase Virtual Inheritance, because (to restate) the C++ virtual keyword has more than one meaning and only one of these meanings relates to VI.
I already put forward earlier that I'm no expert on C#, but if there are two wildly varying meanings for the phrase, one for C++ and one for C#, there should definitely be two separate articles and a disambiguation page.
I am all for an article that contains historical perspective, independent of current languages. I don't think that you've got any content that provides that, though. Not for Virtual Inheritance. Virtual Inheritance in C++ has a single meaning and that has little to do with the virtual keyword, nothing to do with virtual methods (abstract or not) and therefore has nothing to do with your historical quotes (and presumably also your ACM references) because your quores relate to dynamic binding (the domain of vtables and not specifically related to Virtual Inheritance, except vaguely through implementation). If you want this content to go somewhere, explain how C#, or history, makes it relevent to VI or move it to vtable, a seemingly perfectly appropriate article for what you have researched.
And a last point: it may be that your interpretation is not popular because it is wrong. It may otherwise be that your interpretation is not popular because it is original research. Heck, it may also be that many users would agree with you, and you'd have more sway after a vote.
No matter the outcome, I think you are making the wrong move by asserting that if you ever lost a poll that you would have lost because the world holds the incorrect opinion and that you're unpopular, but still correct no matter the result. You're painting yourself a man who will never accept evidence to his contrary and who cannot see that there are many, many other experts in his field, some of whom may know this one topic better than he. Moreover, you're insulting the Wikipedia users who would participate in a poll even before their vote is cast. Pardon my bluntness but not only is that an arrogant display of hubris, it's also political suicide. --Mike Blackney 02:34, 18 September 2006 (UTC)
I have to say I am impressed (and thankful) for your input. I contacted the ACM people and will email them regarding a change in there web site to allow single seaches on papers to display +/- 6 lines around any key phrase seach hits so the context of 'Virtual Inheritance' useage in referenced papers can be viewed by the public. I will also look for usage/history/etc in the papers using your perspective definition (in my mind) to validate your definition and compare aganist what I understand it to be. If I'm wrong on the meaning will we rip out the article and replace it with a correct meaning or attack it with several articles as you suggest. Of course (If I am wrong) I will go out and get a six-pack and tie one on but I've been through worse in my life :-)
The research on the ACM papers (via their online database) is going slow but going. I mentioned and they did seem to fix that one link problem you had (on their site). The search link should work right away (I tested it while on the phone to one of their people).
I prefer 'blunt' responses and appreciate your time, effort and concern. Hopefully our efforts will clarify Virutal Inheritance. I hear what your saying about the voting and, prior to vote or arbitration, look forward to your input and review of my research results. Hopefully we can take the results and rip out the article (If I'm wrong) or have a disambiguation page. I much prefer prior work and fundamental (language independent) principles to be discussed (as we do now) prior to a vote. After that I'll gladly accept whatever the arbitration board wants since (obviously) I'd like to move on from this article and a six pack of beer is still pretty affordable :-)
Shawnktalk—-Shawn wiki 02:49, 25 September 2006 (UTC)

Finally have my plate clear for a few days. Have downloaded over 40 papers from the ACM and will go through these ASAP. Thanks to all for your patience.

Shawnktalk—-Shawn wiki 11:51, 11 October 2006 (UTC)

Mike, I have downloaded 86 papers from the ACM/IEEE/etc covering virtual and implementation inheritance as well as several related areas (functional nomralization, etc). I am finishing up my research an will prepare a summary of the findings on the evolution of 'virutal inheritance' this week. Of course this is only a perspective from the ACM/IEEE/etc but the caliber of the work (especially in one brilliant paper) is more than enough to provide reference material for the dispute. Thanks again for everyone's patience.

Shawnktalk—-Shawn wiki 04:43, 16 October 2006 (UTC)

Mike, I want to thank you for your patience, persistence and professionalism. After reviewing ALL the ACM papers on virtual inheritance I have no choice but to replace the current article with the original article. One paper was especially influential:

Space and time-efficient memory layout for multiple inheritance
Peter F. Sweeney, Joseph (Yossi) Gil
October 1999
ACM SIGPLAN Notices , Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
OOPSLA '99, Volume 34 Issue 10
Publisher: ACM Press

Some quotes from the paper:

"Even though virtual inheritance is a lingual mechanism designed
to support a shared variant of multiple inheritance, the
C++ semantics allows also single virtual inheritance."
Figure 5: A class hierarchy demonstrating shared inheritance: a
class inherited along distinct paths occurs only once in an object.
Inlining of virtual base classes, one of our new techniques, allows shared
inheritance to be loosely coupled with its implementation, permitting the
compiler to choose between a number of different strategies for the
implementation of shared inheritance so as to minimize the space and time
penalties. In other words, we break the bondage between the keyword “virtual”
and the implementation, while still making sure that the implementation that is
chosen maintains the language semantics.

The author correctly identifies 'virtual inheritance' as a form of 'shared inheritance' to clearly articluate the 'sharing' of a single instance of a class that is 'virutally inherited' in C++ (via the 'virutal' keyword).

The pre-ponderance of the use of 'virtual inheritance', steming from the C++ meaning in the ACM papers, precludes the 'language independent' meaning in the article version I have written. Furthermore, and to my own disappointment, I could not find a single use of the term 'virtual code element' within the whole ACM database. So I must admit that I was wrong to generalize and clarify 'virtual inheritance' for a language independent meaning (in the context of WikiPedia :-).

It may interest you to know that core concern of a definitive and fundamental taxonomy of (1) object-oriented programming and (2) inheritance is shared and expressed in several papers on the ACM. One in particular:

The quarks of object-oriented development
Deborah J. Armstrong
February 2006
Communications of the ACM, Volume 49 Issue 2
Publisher: ACM Press
A two-construct taxonomy is used to define the essential elements of object orientation through analysis of existing literature.

Some quotes from the paper.

One reason that learning OO is
so difficult may be that we do not yet thoroughly understand the fundamental
concepts that define the OO approach. When reviewing the body of work on
OO development, most authors simply suggest a set of concepts that characterize
OO, and move on with their research or discussion. Thus, they are either taking
for granted that the concepts are known or implicitly acknowledging that a universal
set of concepts does not exist.
The goal of this article is twofold: to identify and describe the fundamental
concepts, or quarks,2 of object-oriented development, and identify how these
concepts fit together into a coherent scheme.
There were 39 concepts mentioned as those comprising the OO approach (such as
abstraction and dynamic binding). Of the 39 concepts, eight were identified by
the majority of the sources: inheritance, object, class, encapsulation, method,
message passing, polymorphism, and abstraction.

The author goes on to explain a definitive taxonomy for object-oriented programming.

Within this context and within the ACM literature serveral other papers deal with a need for a definitive taxonomy of inheritance (language independent meaning). The semantics of inheritance is of concern (in these papers) along the same lines as the 'quarks' paper.

It is my hope that in the future this article can be revisited and the currently accepted industry meaning of 'virtual inheritance' can be renamed to 'shared inheritance' or something more reflective of its inherent nature.

For the moment however :-) I will put back the original article, clean it up a bit, an add some online references to the ACM papers as you mentioned. I have contacted the ACM orgainization to request changes to the search engine and portal to allow the public the ability see relevant content in the artciles themselves.

The issue of an acurate taxonomy for both object-oriented programming and inheritance I will take up (very briefly) in another WikiPedia article on 'inheritance semantics'.

Thanks again for your request to provide online documentation. I think fullfilling that request is an important aspect to verification and concensus on all the knowledge in WikiPedia.

Shawnktalk—-Shawn wiki 13:46, 23 October 2006 (UTC)

[edit] Article core concept keyword list

The full keyword for the article subject is;

  • virtual inheritance phenomena

The full keyword list for the major core concepts in the article is;

  • code element
  • virtual code element
  • implementation code element
  • virtual control mechanism
  • use context (of the virtual code element)
  • parent use context (of the virtual code element)
  • client use context (of the virtual code element)
  • general virtual inheritance (parent use context)
  • simple virtual inheritance (client use context)

The support concepts that provide the article foundation are;

  • object oriented languages
  • language binding
  • language coupling
  • inheritance
  • lines of inheritance
  • forms of inheritance
  • specification mechanism
  • control mechanism
  • polymorphic mechanism

The incidental concepts that help articulate/contrast the article subject are;

  • type polymorphism
  • implementation inheritance
  • resolution inheritance

The OOL artifacts that help articulate/contrast the article subject are;

  • object
  • class
  • interface
  • method
  • abstract method
  • default virtual method
  • event
  • bool

[edit] Problem space partitioning for knowledge content review/dispute

Please leave this section at the top of the Talk-Discussion page under the keyword list :0)

In order to focus the Talk Discussion process the following 'problem space' is articulated to map proposed solutions to the problems/issues.

For problem discussions (as long as you want) please use the tag 'Problem_Space [X-X] - ' as a section heading.

For solution proposals (as concise as possible) use the tag 'Solution_Space [X-X] ' as a section heading.

The following stratification and enumeration (for both problem_space and solution_space) is for starts. We can change or modify the problem space structure as needed by going deeper ([3-1-1] etc) as needed.

[3] Layer three - SYNTACTIC semantic mechanism of IMPLEMENTATION (design implementation)

[3-1] Control - via syntax expression in some language C#, C++, Java
[3-2] Polymorphism - via syntax expression in some language C#, C++, Java

[2] Layer two - CONCEPTUAL semantic MECHANISM of SPECIFICATION (design specification)

[2-1] Control - via inheritance
[2-2] Polymorphism - via inheritance
[2-3] Scope - Across ALL code elements (clarification of VI vs Virtual Functions)

[1] Layer one - CONCEPTUAL semantic ASPECTS of INTENTION (design intention)

[1-1] Control
[1-2] Polymorphism
[1-3] Resoultion (disputed/needs resolution - This is a valid Syntax semantic meaning in C++)
[1-4] Language independent meaning of VI (Virtual Inheritance)
[1-5] General Virtual Inheritance (language independent context qualifier)
[1-6] Resolution Inheritance (RI) vs Resoultion Virtual Inheritance (RVI)

Of special import is the necessity to talk about any hypothetical languages (say myXYZ computer language) using the WikiPedia definition of 'Virtual Inheritance'. This is a quicker test than requesting someone to read a 1970s IBM paper on hardware design languages to understand the conceptual semantics of event simulation (for example).

See the section (in the article) on Polymorphic Vs. Control Mechanisms to see the above 'concept map/problem space' expressed in English.

Note that layer [1] is the conceptual foundation layer using English dictionary terminology. This foundation provides the mechanisms to write (and vet) computer language specifications, proposals, etc.

In passing - A 'one trick pony' is a 'software expert' that is phenomenally good at knowing ONE language SPECIFICATION (C# V2 for example) and then masquerades its SYNTAX SEMANTICS (basically his limited knowledge) as CONCEPTUAL SEMANTICS for everyone else. We have not had this problem herein - every contributor (so far) to this subject has been excellent. This 'in passing' note is just from years of experience in reviewing/vetting code forums (MSDN, Code Project, etc), software conferences, papers, articles and books.

Please leave this section at the top of the TALK Discussion page so that we can (hopefully) circumvent any semantic/syntax confusion. Hopefully each contributor can be specific and helpful in maximizing the productivity of our joint time in this effort.

Cleanup, formatting and other WikiPedia type changes are not replicated in this section. Please refer to the standard WikiPedia content for such issues and note them below accordingly. Also if you have any recommendations please specify CONTENT, STYLE, CONVENTION in the start of the Talk Discussion section.

We can also track the core problems with the article content. If we need to migrate the problems, then OTHER article authors can minimize their time by using the 'problem space' above.

Please be articulate and focused in your reviews and comments. Please enumerate problem/solutions to the map above for proposed changes to the text.

Thanks ahead of time to all who have worked on this article.

Shawnktalk—-Shawn wiki 15:20, 29 June 2006 (UTC)

PS: Please do not add to this section but start underneath this section with a 'Problem Space : My suggestions/comment/etc' title.

PPS: The knowledge/content of your input should have the caliber expected for legal software patent work. Be articluate, specific and focused :-)

PPPS: If possible partition content rewrites by (INITIAL_TXT : Section) for the current article text, (CHANGED_TXT : Section) for your stuff, (PROBLEM_ON 3-1-1) the enumerated problem location in the 'problem space'. This provides 'grep tags' for Web/Edit tools (like Adobe PDF reader V 7) used by others to list (and hypertext navigate) across all changes.

[edit] Problem Space - [1-3] - Syntactic aspect of implementation as conceptual semantic of intention

Problem : Is VI a state space collision resolution mechanism or a control/polymorph mechanism?

(Is it a floor wax or a mouthwash - or ... is it both :-)

Question 1: Should the C++ SYNTACTIC aspect of implementation (language specific syntactic meaning ) be used as the definitive CONCEPTUAL semantic of intention (language independent conceptual meaning)?

Question 2: Should VI (Virtual Inheritance) mean a 'RESOLUTION' mechanism instead of a 'CONTROL/polymorphic' mechanism?

Question 3: Should a QUALIFIER be added to WikiPedia : 'Virtual Inheritance' (this article) to generalize its current (proposed and in review) conceptual semantics above/aside/beneath the C++ syntactic semantics? (such as 'general VI', 'control VI', etc')

Question 4: Does a better 'prior work - industry standard - in use' term exist for the control/polymorph conceptual meaning of the current (in review) WikiPedia 'Virtual Inheritance' term?

Note 1: Other WikiPedia contributors can take the same stance (MYFAVORITE specific language SYNTAX semantics over language INDEPENDENT CONCEPTUAL semantics). The conceptual semantic point [1-3] is valid however (because of C++ syntax semantics) and needs resolution.

Note 2: The industry NEEDS a definitive LANGUAGE INDEPENDENT definition of VI as defined in the article (control/polymorph semantic). That was the impetus for the article in the first place. Whatever the label (VI, etc) the virtual control/polymorph phenomena in object-oriented computer langugages needs a definitive term.

Below is a code example showing the SYNTACTIC semantics of VI in C++.

In C++ 'Virtual Inheritance' has a RESOLUTION aspect to its SYNTACTIC semantics. Note, the semantics for C++ are syntactic by defintion (i.e. the syntax of C++ and what the compiler produces in the implementation).

In C++ the syntactic semantic of 'virtual inheritance' is a resolution mechanism. See a representative example on the internet below (with URLS for references)

http://www.harding.edu/USER/dsteil/WWW/345/archives.htm http://www.harding.edu/USER/dsteil/WWW/345/EXAMPLES/Virtual%20Inheritance.cpp

From the URLs above - For Example:

class CParent{};
class CChild1 : virtual public CParent{};
class CChild2 : virtual public CParent{};
class CMultiple: public CChild1, public CChild2{};

void main()
{
        CMultiple m;
        CChild1 c1;
        CChild2 c2;

   CParent* p;
        p = &c1;
        p = &c2;
        p = &m;

   // with out virtual inheritance in CChild1, CChild2
  // the following error occures
        // error C2594: '=' : ambiguous conversions
  //                  : from 'CMultiple *__w64 ' to 'CParent *'
}

This code shows the 'resolution' mechanism semantic is valid in the context of C++ syntax.

Resolution could be kludged (in its meaning) as a special case of polymorphism but this would NOT be a correct approach. The 'diamond problem' resolution is actually a resolution of the collision of state space (which instance of the STATE of CParent since all methods, without state, are static in nature - i.e. deterministic repeatable behavior).

All explanations of 'state space collision' and the resolution need to be in the diamond problem article or referenced by the diamond problem article (in WikiPedia) to a page describing the state space collision phenomena and the specific resolution mechanism as mentioned in [1-3].

I highly recommend we solve the problem (what is VI in a language independent context) here and now. People have, do and will continue to use VI in a language independent context. Furthermore VI is used to describe all code elements (state space and method) not just 'virtual functions/methods'.

To keep the argument on the syntactic level of IMPLEMENTATION (Vs specification or intention) is a circular argument (lets listen to Mr. C++, Now lets listen to Mr. C#, ...Ms. Java...).

This article seeks to define VI as a control/polymorph token (of conceptual semantics) but syntactic semantics in C++ conflict with this intention. Is there a better term than VI for control/polymorph semantics in a prior work???

Since an industrywide 'conflict of semantics' does exist (check it out yourself by searching google) solutions to [1-3] need to be enumerated. Enumeration of solutions is NOT SELECTION of solution, enumeration is just PROPOSAL of solution.

Solutions will, for the sake of brevity, be listed in the section SOLUTION - [1-3] - Conceptual Semantic meaning of VI as Resolution Mechanism

Shawnktalk—-Shawn wiki 05:24, 30 June 2006 (UTC)

PS. Please use heading 'Problem_space - [1-3] - MY COMMMENT ON THIS STUFF' for your general comments and proposals. PPS. Please use heading 'Solution_space - [1-3] - MY FIX to the problem' for your very concise and direct solution.

[edit] Problem_space [1-4] : Language independent meaning of VI

Problem : Is Virtual Inheritance (as defined herein - i.e. GVI) a general and intrinsic phenomena of object-oriented languages?

Question 1: Does the industry current use VI as term to compare GVI (as defined) in C$, Java and C++??? (that is to say language independent manner)?

Question 2: Are the control/polymorph aspects of GVI accurate to a test sampling of GOOGLE hits for Virtual Inheritance in C++, C#, Java and other object oriented languages?

Question 3: Do alternate meanings of VI (Resolution aspect of RVI) preclude the existence of GVI (control/polymorph aspect) in other object-oriented languages?

Question 4: Do alternate meanings of VI (Resolution aspect of RVI in C++) preclude the existence of GVI (control/polymorph aspect) in C++?

Statement 1: GVI (as defined herein) is the default meaning of VI in C#, Java and other object-oriented languages.

Statement 2: GVI (as defined herein) is an intrinsic phenomena in C++.

Statement 3: GVI (as defined herein) articulates control/polymorph aspects (of VI) for help in clarifying the concepts of functional aggregation (not object aggregation), functional dispersion, and functional normalization (see link in See Also section : Detailed Inheritance Concepts) along lines of inheritance.

Statement 4: Even in the C++ Diamond context code can be written to show the coexistence of the diamond problem (resolved of course) with GVI. A 'diamond type' derived class can instantiate Virtual Methods defined in the root base class (an example implementation of GVI). As such RVI, an II phenomena (see C++ Resolution mechanism section), CAN NOT EXIST without the 'potential' presence of GVI.

Discussion 1: The intent of GVI articulation is to isolate, identify and encapsulate (semantically speaking that is) the control/polymorph aspect that exists as a inherent and intrinsic phenomena in ALL object-oriented languages. The alternate approach is to take either (1) the RVI meaning (see C++ Resolution Mechanism section) or (2) the C#/Java GVI meaning as the definitive definition. Since the alternate approach is clearly impossible the 'General' qualifier was offered as a mechanism to specify the 'general' phenomena target by the original intent (in this article - i.e. GVI).

Discussion 2: The selection of 'General' as a qualifier follows from standard English semantics. If anyone has a better solution please recommend under the heading Problem_space [1-4] or [1-5] and Solution_space [1-4], [1-5].

Shawnktalk—-Shawn wiki 17:30, 1 July 2006 (UTC)

[edit] Problem_space [1-5] : General as qualifier for VI

Problem : Is the use of the 'General' qualifier appropriate to qualify the 'general' language independent context of Virtual Inheritance as defined in this WikiPedia article?

Impetus 1: Primary impetus is to distinguish RVI (see C++ Resolution mechanism section) from GVI (language independent control/polymorph mechanisms - interfaces, etc).

Question 1: Does current industry practice justify the GVI, RVI qualifications?

Question 2: Is their significant, documented referential work that is also commonly in use in the industry (as opposed to cloistered academia circles) the precedes the GVI term?

Question 3: Is their historical precedence for a three part (three word) terminology to qualify various aspects of inheritance phenomena in object-oriented languages? (such as MII, SII).

Question 4: Is their a better qualifier than 'general' in GVI?

Statement 1: GVI (as defined) is the industry standard meaning of Virtual Inheritance in everywhere BUT the C++ diamond problem.

Statement 2: There is NOT an equalitarian term to GVI (as defined) in the industry (programming).

Statement 3: The GVI vs RVI clarification is VERY similar to Microsoft advertising portraying C# as supporting Multiple Inheritance (MI) (which is technically correct). Originally MI meant MII (Multiple Implementation Inheritance). C# MI means is actually SII (Single Implementation inheritance) with additional Multiply inherited (MI) interfaces. Thus MII, SII helped to resolve the semantic conflict and (correctly) describe C# as a SII language that does not support MII. This removed any conceptual semantic confusion of C# as supporting MII (via the MI definition advertised by Microsoft). The point being that GVI and RVI can correctly identify the conceptual semantics of Virtual Inheritance in the 'C++ Diamond Problem'/'Everywhere else' context just as SII and MII have distinguished II (Implementation Inheritance) in industry nomenclature.

Statement 4: When talking in a language independent context VI means GVI. Do an Internet search for 'Virtual Inheritance' with the phrase 'language comparison'. The hits tend to discuss the C#, Java VI meaning and indicate the current obsolescence of the meaning IN THE LANGUAGE INDEPENDENT CONTEXT (RVI meaning still VERY valid in C++ diamond problem discussions).

Discussion 1: The semantic history section combined with the semantic scope section should qualify the validity of RVI in the C++ historical context. In addition the GVI context, useful in MII conversations about C# and future languages for example, clearly defines the 'general' context.

Shawnktalk—-Shawn wiki 18:19, 1 July 2006 (UTC)

[edit] Problem_space [1-6] : Resolution Inheritance (RI) Vs. Resolution Virtual Inheritance (RVI)

Problem : Should the historic 'Virtual Inheritance' (keyword based meaning - ICA/MOA) term of C++ be demoted in favor of a more accurate and language independent term (IN THE CONTEXT OF THIS ARTICLE) - in favor of the term 'Resolution Inheritance'.

Impetus 1: The core phenomena of inheritance needs to be clearly articulated to explain Virtual inheritance (GVI/SVI) in this WikiPedia article. Key terms explained are virtual code element, parent use context, client use content.

Question 1: Is the article confusing when it places C++ syntax semantics over language independent conceptual semantics (see Semantic Scope section).

Question 2: In this article is it easy to understand 'Resolution Virtual Inheritance' as a term that has NO conceptual semantics related to Virtual Inheritance (GVI).

Question 3: In this article is the language independent meaning to be used everywhere including C++ sections.

Statement 1: For non-C++ programmers the use of the C++ syntax 'virtual' keyword (syntax semantics) is confused with the conceptual semantics of a 'virtual' code element controlled by the parent/client (GVI/SVI).

Statement 2: For senior C++ programmers (over 10 years) the use of the syntax semantics to explain conceptual semantics is confusing when taking about general language independent issues such as virtual, implementation, resolution and polymorphic (casting) inheritance phenomena.

Statement 3: After several private reviews from Senior C++ programmers (proficient in other OOL languages) the use of RVI (Resolution Virtual Inheritance) was deemed confusing and inappropriate for software patent level work where the conceptual semantics must be clear and simple.

Discussion: This article is currently in cleanup prior to a request for review, consensus and potential arbitration (if any). As such some cleanup seeks to simplify the article and have it adhere to WikiPedia standards and conventions. Links to another topic map based article on inheritance semantics will address the context of meaning in object-oriented inheritance. To minimize their time the 'final review' version will be as simple as possible. As such the language independent RI (Resolution Inheritance) term will be used over the RVI (Resolution Virtual Inheritance) in the context of this WikiPedia article.

Summary: Please title all comments to this issue as 'Problem_space [1-6]' and alternate solutions as 'Solution_space [1-6].

PS. As always we can tear the heck out of the article after its done :-)

PPS. This means that some sections can be spawned off on their own if need be (See also topic map, etc).

PPPS. Several sections of the development version of the article were spawned off. Also some code sections that dealt with implmentation inheritance phenomena.

Shawnktalk—-Shawn wiki 13:50, 6 July 2006 (UTC)

[edit] Problem_space [2-3] : VI Specification scope limited to functions/methods

Problem : Is Virtual Inheritance applicable to only methods (as in Vtables, Virtual Functions) or does it also apply to any other code element?

Question 1: Do the conceptual semantic aspects of control and polymorphism preclude other specification mechanism than functions/methods. For example - Is it theoretically (read that conceptual level semantics) possible for VI to 'control and polymorph' state space (variables, fields, delegates) in some hypothetical future language.

Statement 1: C# Interfaces (a subset of GVI) are inclusive of properties, indexers and events. Since VI and interfaces are a 'specification' phenomena VI, in this case, includes more than just methods. Properties, indexers and events are special types of callable functions in practice. In reality however events (delegate wrappers for multi-delegate constructs) have 'state space' associated with their inherent function (thus state space is controlled via VI-Interface). Properties also are 'wrappers' around state. Subsequent binary code (to change state) is not precluded by the VI meaning (as presented in this article).

Discussion 1: Currently there is no semantic aspect that restricts VI to any particular code element. The control mechanism (parent centric) does not specify 'what' it controls. The polymorph mechanism (child centric) does not restrict 'what' is 'polymorphed' (sp - so to speak).

Shawnktalk—-Shawn wiki 17:09, 1 July 2006 (UTC)


[edit] Solution_space [1-5] - General qualifer in GVI

The qualifier 'General' has been chosen to distinguish the 'general' language independent context of VI.

Problem_space [1=5] 'General' as a conceptual semantic context qualifier refers to the 'general' language independent context of VI. Historically Virtual Inheritance has two language SPECIFIC meanings: GVI (control/polymorph) and RVI (resolution) (see article). GVI and RVI was chosen to follow the MII, SII practice currently used by the industry to qualify differences in Implementation Inheritance.

Statement 1: GVI, RVI reflects into VI what MII and SII put into Implementation Inheritance.

Statement 2: VI (Virtual Inheritance) and II (Implementation Inheritance) each contain subset forms of a general inherent phenomena in object-oriented programming (via GVI-RVI, MII-SII). The general forms VI/II are intrinsic to ALL OOL (object-oriented languages).

Statement 3: GVI (as defined) exists (and has always existed) in C++ as an intrinsic feature of inheritance (in C++).

Alternative 1: Instead of 'General' to imply 'language syntax independent' the qualifier 'Control' could have been used to imply the control aspect of GVI. The language independent aspect was seen as better emphasis for the current use of GVI (how VI is used in day to day forums for language independent comparisons of VI). in programming forums.

Alternative 2: Instead of 'General' to imply 'language syntax independent' the qualifier 'Polymorphic' could have been used to imply the polymorphic aspect of GVI. This is technically not (however) a required condition since single (straight) lines of inheritance (without peer children to polymorph) can still exhibit the control aspects (parent centric) of

Discussion 1: Since the article is still in review I will do some research on the 'semantic history' of virtual inheritance by contacting some of the language founders. In the mean time we can use GVI/RVI until a better recommendation to solve the problem_space[1-3,4,5] problem set comes along.

Discussion 2: Since not everyone is NOT going to drop everything and review the article please leave the GVI/RVI intact and make recommendations in the discussion section. Final decisions will be by concensus and arbitration if needed.

Discussion 3: There is historical precedence for 'General' designation but such precedence is semantic/linguistic. The best precedence IMHO is the MII/SII terms combined with the need for a language indepedent designation (thus the choice of 'General' as the qualifier.

Shawnktalk—-Shawn wiki 18:53, 1 July 2006 (UTC)


[edit] Solution [2-3], [1-4] : Semantic Scope Section

A section entitled 'Semantic Section' has been added to solve the problem_space [2-3] - 'Specification scope'.

It also solves problem_space [1-4] 'Intention of language independence'

Problem_space [1-4] : The Semantic Scope section is explicit that Virtual Inheritance (as defined in the article) is a 'General' concept (language syntax independent).

Problem_space [2-3] : The Semantic Scope section is explicit that Virtual Inheritance (VI) includes more than just functions (Vtables, Virtual Functions). Case in point is C# Interfaces where Properties and Events can be specified (in the interface) and then inherited (Via VI).

Shawnktalk—-Shawn wiki 17:09, 1 July 2006 (UTC)

[edit] Solution_Space [1-3] - Section on resolution mechanism for diamond problem

A section, under C++, should be added to explain that when discussing the diamond problem the term 'Virtual Inheritance' means the resolution mechanism (Level 2 - Design Specification) of the C++ 'virtual' syntax (Level 3 - Design Implementation) that resolves the state space collision issue in the diamond problem.

The section should be very brief with links to the WikiPedia diamond problem article.

The section must contain example code (Level 3) showing the syntax that resolves the diamond problem.

Shawnktalk—-Shawn wiki 11:36, 30 June 2006 (UTC)

Section 2-3 (current article version) is now ready for review. This helps to solve the [1-3] problem. We still need the section on semantic history but the research takes a little more time.
Note the use of 'General Virtual Inheritance' as a qualifier for the language independent meaning as defined in this article. This qualifier (General) is noted as problem_space [1-5] to emphasize the language independent context of the meaning as defined in this article.
Shawnktalk—-24.12.95.75 13:41, 30 June 2006 (UTC)

[edit] Solution [1-1,2,3,4,5] : Stateful Diamond Point pattern/example

A section entitled 'Stateful Diamond Point pattern' section has been added to take care of all conceptual semantics in a single pattern.

A section entitled 'Coexistence of GVI and RVI in C++' has been added which has the 'High State Tracker' example code.

Problem_space [1-1,2,3,4,5] : The pattern/example shows control [1-1] without polymorphism [1-2]. C++ Resolution ([1-3]) RVI coexisting with control (GVI). GVI as existing in C++ [1-4]. GVI in C++ as being comparable to other GVI syntax semantics (C#, Java) relative to the control aspect.

The SDP pattern is also useful to show GVI in the context of other language (C# and Java).

Shawnktalk—-Shawn wiki 17:09, 1 July 2006 (UTC)

[edit] Original Dispute status from Early June 2006

All disputed references have been fixed.

Additional sections were added to clarify all major semantic aspects of Virtual Inheritance.

Still need to add the classic figure/circle/square/triangle code example.

Will pull this article from the disputed section since all concerns (see below) have been taken care of and the content has been reviewed by others.

Also will add various references following the classic code example for Virtual Inheritance.

Shawnk Fri 06/23/2006

I need to know how to start the process of dispute removal

Any help is greatly appreciated.

--Shawn wiki 14:52, 26 June 2006 (UTC)

If you are sure the dispute is over, get a senior consultant to remove the tag. If it is not over, someone is bound to re-add it & specify why. --Tagishsimon (talk)
I finally figured out how to remove the dispute via the 'dispute tag'.

I've contacted all the WikiPedia users in the discussion and will wait for there response. If no objections come in I'll remove the dispute status. Thanks tons for your help on my first dispute resolution :-) --Shawn wiki 15:40, 26 June 2006 (UTC)

Thank you so much :-)

[edit] Problem Space - What the heck?

"It allows a parent to control code implemented in the children which inherit from it." With regard to C++, this is not what Virtual Inheritance means. When speaking of C++, this comes under the topic "Virtual Functions", or perhaps "Inheritance" or even "Type polymorphism". I see that C# (a language I'm not very familiar with) has redefined the term for its own needs, but that only proves that perhaps there should be two pages for Virtual Inheritance - perhaps Virtual Inheritance (type polymorphism) and Virtual Inheritance (C++). When speaking of Virtual Inheritance and C++, this is never what is meant.

With respect to C++, Virtual Inheritance is different from normal inheritance, and ensures that derived classes in multiple inheritance hierarchies contain only one object of the base class. It is a necessary distinction since it is not always desirable. It seems that C# has recommissioned this term, since it doesn't have multiple inheritance in the true sense, and as such doesn't need two forms of inheritance.

The two concepts are disparate, and I feel that someone who understands both of them back-to-front needs to get in here and help out. Failing that, I can break off relevant content for the C++ page.

As it is, the article has little to no information about VI in the C++ sense, and since this is still the primary use of the term, this article needs to change. --202.164.194.254 03:04, 30 June 2006 (UTC)

"derived classes in multiple inheritance hierarchies contain only one object of the base class". Just want to clarify the following. Your are stating that
[1] Virtual Inheritance ensures only one implemenation of a multiply referenced base class exists in a derived object where a diamond problem exists.
Is this your understanding of VI???
If so I'll put 'this' definition in the problem map. I wrote the article to clarify just this issue relative to C++, Java, C# and other languages. What is VI IN GENERAL. It is my understanding, from references, etc. that Virtual Inheritance is a control/polymorph mechanism. Could you verify the [1] definition and summarize what the conceptual semantic aspect is? From your text you present the semantic as a selection mechanism to resolve ambiguity, a (multi-reference) resoltion mechanism to solve a diamond problem, something along this line??
So then you state there is no (A) control aspect or (B) polymorphic aspect to its semantics??? Is this what your saying???
I have found enough hits, via google, to show both semantics are used AND are used for all lanauges (C++, C#, Java). I agree, and that is the point of the article, that a concensus, backed by prior work and references is needed. I especially want to go beyond the SYNTAX SEMANTICS of any one language towards a VI definition that reflects current use to compare features in many lanauges (such as you propose). I'll do a little more research and open up your excellent point (about VI in C++) in the problem map.
Note that in our industry prior work, paraellel independent work, etc lead to multiple defintions of terminology (which is real pain). Hopefully we can resolve the SYNTACTIC SEMANTICS from the conceptual semantics correctly. If we need, after much consideration, to de-construct and re-construct the article then we will. But only after a strong concensus. Give me a day or two for additional research and I'll add your excellent point to the problem map :-)
Shawnktalk—-Shawn wiki 03:29, 30 June 2006 (UTC)
I have opened up Problem_space [1-3] to resolve this important point. I have two sections to recommend to resolve it. (1) SHORT Section on semantic history of VI and (2) Section under C++ on the resolution mechanism for Diamond Problem.
After some consideration this is not a show stopper. VI, as defined, still exists as a major feature of C++. After 14 years of C++ I use VI to signify the semantic meaning as defined in this article. I never used VI to signify the resolution mechanism since I my code is always functionally orthogonal (see link in article). I do agree that in the context of the C++ diamond problem the resolution mechanism meaning takes precedence but this term is becoming/has been obsolete (IMHO). Please refer the relevant discussion on a 'lanaguage independent' emphasis in the problem [1-3] sections.
Thank you for your valuable input. The final decision will be by concensus and we will seek arbitration if we need to help us provide the best language independent meaning possible.
Shawnktalk—-Shawn wiki 11:04, 30 June 2006 (UTC)
VI, as defined, is only used in C++ when you write 'class y : virtual public X' or 'class Y : virtual private X'. It is not the same as normal inheritance, which you seem to be confusing it with. Regular inheritance is covered more than amply in its own article.
I have removed any hint or reference to obsolescence of the term 'Virtual Inheritance' relative to your concerns.
Furthermore I qualified, quite cleary, the term 'Resolution Inheritance' is used in the context of the article
to avoid confusion and provide clear, explicit articulation of the concepts herein.
I will review the article again this week to ensure that your concerns are addressed in the best possible
manner without confusing the content and changing the logical meaning of the text.
Shawnktalk—-Shawn wiki 16:14, 17 July 2006 (UTC)
The term is not becoming obsolete, and will not because Virtual Inheritance (as opposed to Inheritance) is used extensively in most libraries, including the STL. Virtual Inheritance is, in C++, there to remedy the diamond problem. The term should not be confused with Inheritance (which is an adequate, and frequently used, term representing much of what is in this article, and also has its own article) and, although it may have been hijacked for use in new languages without the diamond problem, it is still used primarily for the use which I have outlined. --202.164.194.254 00:45, 14 July 2006 (UTC)
After satisfing your obsolescense concern I have some issues with your other points.
On several other points I could not disagree more strongly in any possible sense of the word.
Because I strongly disagree with several statements in the above
I have addressed each point in the rebuttal section below.
Shawnktalk—-24.12.95.75 14:00, 21 July 2006 (UTC)
Please see the (basic - not advanced) logical spectrum analysis for content replication on 'virtual inheritance' in the sections below.
Shawnktalk—-24.12.95.75 14:16, 21 July 2006 (UTC)
Several of our associates and peers have reviewed the current content and feel your valid concerns have been meet.
We are still cleaning, touching up and reviewing the article.
Since the article is free standing (based on the code) please review the code and the documented phenomena in the code.
Hopefully no other references are needed (free standing) and the code demos the relevant VI phenomena (VCM, Virtual code elements, use context).
We have endeavored to articulate your terminology concerns with the utmost diligence.
Citations, research list and index will be added after the code/content (and closely related articles) survive the WikiPedia dispute process.
Please feel free to perform a terminology substitution (offline of course) with the content if you feel better terms exist.
We look forward to any further recommendations you may have.
Shawnktalk—-Shawn wiki 14:45, 21 July 2006 (UTC)


Code examples----------rebuttal by shawnk----------------------------------

I have added the C# SPD (diamond problem) example and its summary to compare and show Virtual Inheritance as an inherited 'virtual code element' specification that has important use context aspects.

The definitions herein are all related to a language independent meaning of Virtual Inheritance as specified in the introduction.

Minimal information to support article focus------

The core conceptual aspects of VI (language independent) are given in their minimal form without much of the intricate implementation problems found in many Internet sources such as;

http://www.ddj.com/dept/cpp/184402074

While these articles are excellent and detailed we have tried in this article to be as minimal as possible (in order to be definitive). As such this article is meant to be closed, complete and free standing.

Language independence------------------------------------

The summary sections of each language section (C#, C++, Java) focus on the language independent phenomena and definitions for the very reason you mention..

....although it may have been hijacked for use in new languages....

As stated, this is a major impetus to the article, i.e. Virtual Inheritance what is it? This definition is the language independent meaning as outlined in the article text.

My version not others------------------------------------

....it is still used primarily for the use which I have outlined....

I strongly disagree. Having 14 years (solid) in C++, 5 in C# and 3 in java (roughly) virtual inheritance is used as specified in the article. The 'Virtual Inheritance' of C++ due to the 'virtual' keyword is covered in the beginning of the C++ section.

Although I do not discount your point, the article is about not about Resolution inheritance (RI) and brings up RI to clearly state as much. RI has been known since the early days as different from Virtual Inheritance. I could not even write this paragraph without this vital and important articulation (RI as a term).

Having met with and talked with Walter Bright in 1989 (first commercial C++ compiler - my first C++ compiler - Zortech if I recall correctly - bought out by Symantec) the difference between a keyword ('virtual') and a conceptual concept has been a well known difference for some time (in the early days of C++, C-Front). Even in the C++ community the concept of 'specification via inheritance' (virtual code elements) is clear (as outlined in the article).

What do you suggest everyone else (C# community, Java community) do relative to the concept of Virtual Inheritance (not the C++ key word)?

Examination of Numerous hits on Google show the meaning (as in the article), as used in C++, C# and other languages is valid. Just look at the code examples (that's why they are there).

Are you saying the 'virtual code elements' with a 'use context' do not exist??? Is GVI/SVI/VI/Resolution Inheritance all really the same thing? (see article for differences).

WikiPedia, and this article, is targeted to be of benefit to all communities (C#, C++, Java). This 'independent' focus of the article content is pretty well layed out with this intention.

Replicated material--------------------------------------

You also seem to infer the content in this article is contained in other articles.

.....The term should not be confused with Inheritance
.....(which is an adequate, and frequently used, term representing much of what is in this article (?????-shawnk)
.....and also has its own article)

In reviewing the article (again) on the inheritance (that you mention) there is no mention of 'virtual code elements' (VI) that have a 'use context' (GVI/SVI). I also reviewed many of the other articles (again) linked on the 'inheritance' page. They also did not cover this material. If you check the article you mention:

There isn't even a section on virtual inheritance (as of July 14 2006) in the article. Just looking at the article you reference - I did the following logical spectrum (for content replication). Note the following search hits in the article you mentioned;

  • resolution - 0
  • virtual inheritance - 0
  • Virtual code element - 0
  • use context - 0
  • pattern unit - 0
  • lines of inheritance - 0
  • functional normalization - 0
  • object aggregation - 0
  • object composition - 0
  • virtual - 1 (a link to this article on Virtual Inheritance)
  • specification - 1 (not applicable)
  • implementation inheritance - 6 (a negative presentation all under code-reuse)
  • implementation - 9

Compare this with the same logical spectrum in the July 14 version of this article:

  • resolution - 42
  • virtual inheritance - 147
  • Virtual code element - 26
  • use context - 37
  • pattern unit - 12
  • lines of inheritance - 9
  • functional normalization - 9
  • object aggregation - 15 (used in C# example)
  • object composition - 1 (a link to section on - not used in examples)
  • virtual - 276
  • specification - 53
  • implementation inheritance - 21
  • implementation - 85

According to you the two articles cover Virutal Inheritance equally??? Is this what you infer???

I fail to see the how it can be inferred that this article is about 'inheritance' and not 'virtual inheritance'. The article on inheritance is an overview of inheritance. The links at the bottom of the article are a testament to its avoidance of covering everything in one article.

This article, on the other hand, is solely focused on understanding Virtual Inheritance. This article is meant to be accurate, complete, closed, focused and definitive.

Please let us know if another WikiPedia article exists (to this date - July 14 2006) that articulates the 'use context' of 'virtual code elements' as the difference between GVI and SVI.

Adequate (????) ------------------------------------------------

.....The term should not be confused with Inheritance (which is an adequate ... term )

I could not disagree more strongly in any possible sense of the word.

To equate GVI/SVI/VI/RI in this article as synonomous with 'inheritance' is an interesting proposition. Why don't you take the text of the article, do a substitution (including the expanded formats) and just read the content.

The content would literally make no sense (we actually tried this).

To infer that the articulation of conceptual semantics in this article should be replaced by a non-sensical (and callous) use of 'inheritance' for [GVI/SVI/VI/Resolution Inheritance ] (i.e. inheritance/inheritance/inheritance/inheritance) would also undermine the core meaning of the term 'inheritance' itself (as a attributive denotation for its various forms - note that GVI/SVI/VI/RI all end in 'inheritance' :-).

Bias and term obsolescence relative to C++ Virtual Inheritance----

...The term is not becoming obsolete
...Virtual Inheritance is, in C++, there to remedy the diamond problem

We share your concern that the article is unbiased (if indeed you infer this) and have taken extra care to use the term 'Resolution Inheritance' so as not to confuse the content of the text.

We tried the 'virtual inheritance' term in earlier versions (please review them). The text was confusing and not readable.

Furthermore we have stated in the introduction and explained in the C++ section the issues you mentioned.

Best possible use of terminology--------------------------------

Our core intent is to have accurate content on Virtual Inheritance as it exists in object-oriented languages.

We are still cleaning up the article and will endeavor to take your input into account. As always the core terms for [VI/GVI/SVI/Resolution Inheritance/Virtual code elements/use context] can be replaced with industry standard terminology (should they exist).

An alternative is to remove the content (from WikiPedia) and pursue other venues of publication (Dr. Dobbs, Code Project, ACM, OOPSLA, etc.) .... which, clearly, we do not want to do.

Since our reference list and research index are centric to the credibility of the content we are confident that the material (herein) is valid. More to the point the code examples are mean to be free standing and definitive. Is there a problem with the code?

The content was not meant to be good article on Virtual Inheritance. It was meant to be the best article on Virtual Inheritance.

Please be patient and allow us more time to complete the article for final review, dispute and consensus. We are confident that the language independent focus is EXTREMELY relevant to the programming community (as your comment on 'hijacked' and all of your input shows).

WikiPedia was chosen as the publication venue to resolve the confusion surrounding Virtual Inheritance ... not to perpetuate it.

Thanks, as always, for your input.

Shawnk

Shawnktalk—-Shawn wiki 17:29, 14 July 2006 (UTC)



The classic C++ concept of virtual inheritance has been articulated
as per your observation. The links below cover the
relevant sections.
Please feel free to add any additional comments as per the problem space map above.
Also thank you for your patience as it takes time to research, phrase, veryify
and privately review problems in the article text.
After the current clean up process (stable content) we will expand our review process
as you suggested. We will also be contacting some industry leaders for
their review of the semantic history.
Finally, after dispute and any arbitration we will put in the research reference list.

Shawnktalk—-Shawn wiki 16:00, 6 July 2006 (UTC)

If nobody can be bothered to give a single reason why this needs cleanup, the tag should be removed. TMLutas 21:47, 18 May 2006 (UTC)

This page looks pretty dodgy to me. 'Virtual inheritance' really only relates to the C++ example with the Animals. The use of 'Virtual inheritance' as a synonym for 'Polymorphism' is incorrect. In addition to this, the C++ code needs to be cleaned up as it is not compilable code. --202.164.194.254 22:15, 24 May 2006 (UTC)
I agree. This article looks wrong. I would expect this article to talk about the construction class foo : virtual public bar { .... There is the distinction between overriding a regular function in C++ and overriding a virtual function in C++ since the prior gives run-time polymorphism, but this page should probably mention that and link to virtual function. —Ben FrantzDale 14:36, 25 May 2006 (UTC)

Page is very important ------ shawnk -------

I think this page is very important and should definitly be kept in.

The difference between Virtual Inheritance (VI) and Implementation Inheritance (II) is STILL not articulated well in OOL (Object Oriented Langagues) terminology (IMHO).

I constantly see questions relative to confusion between the two (VI and II). Wikipedia has been very helpful as a reference to distinguish between VI and II concepts. I would like to see an article on II with a link to this article.

C++ has II and VI. C# has only VI (interfaces) and only single II (via single inheritance). So what are the best terms to discuss this difference in II between C#, C++ and other OO languages?

Does 'Type Polymorphism' distinguish between inherited functionality (as in II of multiple inheritance) and locally implemented (as in VI) functionality?

Also how does 'Type Polymorphism' qualify the inheritance of interfaces (C# functionality specification) from the inheritance of function (C++ multiple inheritance).

The relationship between 'Type Polymorphism, Implementation Inheritance (as in C++ mulitiple inheritance and C# single inheritance) and 'Virtual Inheritance' (as in C++ abstract class inheritance and C# interfaces) needs to be clearly articulated in three separte articles that are linked together.

Yep - I was thinking the same thing. I believe a lot of the content that is presently in the page needs to be deleted or moved to its correct sections (II or Type polymorphism) and it needs to be cleaned up so it better explains VI. If nobody objects, in a week or so I'll see what I can do. --202.164.194.254 01:35, 9 June 2006 (UTC)

[edit] Some hints for a cleanup

From the point of view of somebody who doesn't already know what virtual inheritance is (i.e. me), this article presents some difficulties:

  1. In the sentence starting "It allows for a derived object to be used as its base object...", what does "its" refer to? Whose base object?
  2. I can't parse this sentence: "C++ has two uses virtual inheritance to solve both disambiguity problems caused by multiple inheritance and virtual method overriding." Is "uses" a verb or a noun in this sentence?
  3. I don't think disambiguity is a word -- or does it have a specific meaning in this context? Even so, surely it should be "ambiguity problems" rather than "disambiguity problems"?
  4. In the sentence "Normal method overriding is limited to the context of the objects current casting", it seems that what is meant is object's rather than objects.

Ferdinand Pienaar 16:01, 12 June 2006 (UTC)

[edit] Clean up suggestion

The following suggestions seek to improve the articulation of the statements noted by Ferdinand Pienaar.

[edit] 1-org

It allows for a derived object to be used as its base object ...

[edit] 1-new

Virtual Inheritance (VI) is a fundamental feature of most object-oriented languages. Virtual Inheritance allows for a derived object (the child) to be used by the base object (the parent).
In Virtual Inheritance the child inherits ONLY the specification of the method

defined in the parent. As such the child is FORCED to IMPLEMENT the functionality specified in the signature of the abstract method.

Virtual Inheritance (VI) is contrasted with Implementation Inheritance (II) (link) where the child (the derived object) inherits an IMPLEMENTATION of a function defined by the parent (the base object).
A 'pure abstract method' (link) is one defined by the parent with no 'default implementation' (link).

Pure abstract methods are the definitive expression of Virtual Inheritance as they embody the forced implementation in the child by the specification in the parent.

Pure abstract methods are 'signature only' specifications which leave the implementation to the child. the signature specification (of the abstract method) is the mechanism that allows the parent to call the child without knowing the details of the child's implementation of the parents specification.
Virtual inheritance is the core impetus for Interfaces (link). With Interfaces a child inherits ONLY the specification and NOT the implementation of a method.
Note that in some languages a virtual method CAN OPTIONALLY provide a default implementation (link) of a virtual method. This does not detract from the semantic meaning of Virtual Inheritance which is the ability of the parent to call child implementation.
Note that in cases where a default implementation is provided by the parent the

current casting context will determine which implementation (child or parent implementation) is used.

Note also that in Type Polymorphism the child may use both its

implementation (defined in the child code body) and the parents implementation (of the virtual method) in implementing the child's version of the target functionality.

The pure abstract method and forced implementation are what distinguish Virtual Inheritance (VI)

from 'Type Polymorphism'.

[edit] 2-org

C++ has two uses virtual inheritance to solve both disambiguity problems caused by multiple inheritance and virtual method overriding.

[edit] 2-new

C++ has two intentions in its use of Virtual Inheritance; To solve both (1) ambiguity problems caused by multiple inheritance and (2) virtual method overriding.

[edit] 3-org

C++ has two uses virtual inheritance to solve both disambiguity problems caused by multiple inheritance and virtual method overriding.

[edit] 3-new

C++ has two intentions in its use of Virtual Inheritance; To solve both [1]

ambiguity problems caused by multiple inheritance and [2] virtual method overriding. The ambiguity problem (link) occurs when the compiler must select one of many class candidates for the inheritance. The diamond problem (link) is a well known example of the ambiguity problem.

[edit] 4-org

Normal method overriding is limited to the context of the objects current casting.

[edit] 4-new

Normal method overriding is limited to the context of the object's current casting.


I just noticed that the Multiple Inheritance WikiPedia page has a link to this page (Virtual Inheritanc).

I highly recommend that a change be put in to place a 'See Also' section that provides a link to both the Interface Page and the Multiple Inheritance page.

—Shawnk

To clarify why Type Polymorphism is a superset of Virtual Inheritance I suggest the following changes to my earlier suggestion.

If no one has any objections I will incorporate these changes this weekend into the Virtual Inheritance definition for general review.


—Shawnk

PS. I will try to contact the other authors/commenters via email to coordinate with them on this.

[1-org]

The 'pure abstract method' and 'forced implementation' are what distinguish Virtual Inheritance (VI) from 'Type Polymorphism'.

[2-new]

The 'pure abstract method' and 'forced implementation' are what distinguish Virtual Inheritance (VI) from 'Type Polymorphism'.

Thus 'Type Polymorphism' (TP) is a conceptual superset of 'Virtual Inheritance' (VI) in that TP functionality can be composed of child AND parent implementations while VI functionality is (by definition) the child implementation.

By having the critical distinction between VI and TP we can isolate issues/problems related to VI that can be solved with a TP design approach (the addition of supporting parent functionality to augment the child functionality).

This distinction between TP/VI also allows a more articulate definition of the 'virtual' control the parent can exhibit over the child's implementation in a purely VI context.

Note that 'Type Polymorphism' (TP) has such a rich history (see WikiPedia - Type Polymorphism) that Virtual Inheritance (VI) allows for the clear designation of 'virtual control'.

I think the definitions and suggestions discussed above should be put prior to any historcal/reference sections.

After the definition is vetted (and changes posted on main page) a terminology/conceptual history/reference section, similar to that found on the page for 'Type Polymorphism' should be started.

This would help to complete the definitive nature of the definition of Virtual Inheritance.

Finally I will write up and enter an initial definition of Implementation Inheritance to provide for the linkage (to it) defined above.

Following the history/reference I suggest a code sample for this page to the classic Figure/Circle/Square/triangle Virtual Inheritance (VI) example be put here.

If the classic Figure/Circle/Square/Triangle code sample exists else where the we should link to where it is and consider moving (the sample code) to this page as a definitive expression of (pure) virtual inheritance.

Shawnk


Polymorphic mechanism vs Control mechanism

In re-reading the Type Polymorphism page I note that Virtual Inheritance has both a polymorphic and control aspect.

The 'virtual control' aspect is the ability of a parent to call a 'virtual implementation' that is ultimately implemented in the child.

The 'polymorphic' aspect is the ability of the child implementation to 'type' the functionality (of its virtual method implementation) to the child's specific needs (for that functionality).

In articulating these two aspects the relationship of Virtual Inheritance to Type Polymorphism becomes clear. This explicit articulation (of the polymorphic/virtual aspects) will also help to strengthen the clarity of Virtual Inheritance from Multiple Inheritance (MI), Single Inheritance (SI), Implementation Inheritance (II) and Interfaces.

Shawnk

After re-reading the 'Language' section and researching older programming books and references I disagree with the 'solve .. problems' statement (see section on polymorphic/control).

It sounds as if the writer was a post java/C# world programmer with less that five years of coding in C++. Also sounds like the writer was not 'there' in the time frame (1989 - 1993) in the early days of C++ prior to its general use in industry software products.

I suggest the 'C++' section talks about syntax and implementation issues with virtual inheritance.

There was 'no problem' with virtual inheritance relative to ambiguity. Ambiguity is a phenomena that results from the implementation inheritance aspect of multiple inheritance.

Shawnk

The correct definition of Virtual Inheritance as been entered into the article. The point of dispute -

> The use of 'Virtual inheritance' as a synonym for 'Polymorphism' is incorrect.

.. has been articulated and a 'see also' section put with links to other concepts that are related to Virtual Inheritance.

Please review the full article and I will remove the disputed entry for this article.

Finally, if there are any more disputes, please be (1) very specific and (2) give alternate content to make your point (of dispute).

Should no disputes come up in week I will remove the disputed entry and put in external links to various references to correlate the current content of the article.

Shawnk

[edit] Cleanup

Please do not add to this section but form a new one stating WHY you think the article needs to change.
Please do not repeat the 'C++ only' viewpoint without historical references to ACM papers, etc.
Also make a profile so we can see who you are.
Finally, to make it easier for the 'C++ keyword folks' - look at the last line in the article in the quotations section (as well as the progression of thinking over the last few decades. If you think that virtual inheritance only exists because the C++ keyword 'virtual' please prove that language independent (and historically accurate) does not exist. Perhaps the ACM papers on the history of object oriented programming are wrong and you can enligthen us on what virtual inheritance really is :-)
Shawnktalk—-24.12.95.75 13:29, 1 September 2006 (UTC)


I re-added the cleanup tag to the article. Several things are non-standard about this article that should be addressed. The "See also" section is far longer than it needs to be; it also doesn't follow case conventions and so has many "piped" links. I believe "See also" sections generally have just the name of the link and sometimes some description of why it is relevant. Also, many emphasized terms are capitalized. If they really diserve emphasis, they should probably be itallicized or "quoted". —Ben FrantzDale 16:31, 27 June 2006 (UTC)

As for content, I wonder if this page should really focus on virtual inheritance in the C++ sense of class foo : public virtual bar {...}; rather than focusing on virtual functions.—Ben FrantzDale 16:35, 27 June 2006 (UTC)
Thinking about it a bit more, I think this article should probably start with “For inheritance of virtual functions, see virtual function or vtable.” and then go on to say “In object-oriented programming virtual inheritance is a special sort of inheritance found in C++ [any others?] in an attempt to solve problems with multiple inheritance. If class A is inherited virtually by classes B and class C and then class D inherits both B and C, then an instance of class D will have only one copy of class A so that a call from C to A::foo() is unambiguous.”
We should get consensous if this is really what “virtual inheritance” means, but any other meaning seems to me to be covered by vtable and virtual function. —Ben FrantzDale 02:55, 28 June 2006 (UTC)
I think concensus with reference back up is key on the whole point of 'what VI means'. I have 14 years C++, 3 java, 5 C#, plus numerous assembly/simulation/HDL languages (about 27 years total). I've seen so many 'one trick pony' experts in the code forums (MSDN) who are so fixated by a particular language spec (Java, C# 2, etc) that they can't see beyond their own spec :-) I attended serveral OOPSLA conferences in the late 1980s and want to emphasize the language independent definitions is all cases (II, VI, etc).
On the topic map I want to complete it and then get advice, after review, of moving it to its own short and focused page. Many newer programmers have difficulty distinguishing the subtle nature of design approaches (inheritance, Object aggregation, object composition) from mechanisms and problems. So I started the topic map approach to get reviews on it and then to move it (with links to it).
I hope to speed up the JOINT review, concensus and release process by putting all the 'cards on the table' so to speak prior to any 'reference wars'. That way we can all focus on the pure language independent (Java, C#, HDL, C++) semantic aspects and then quote the relevant passages in any references. Finally any tangential issues or content can be stripped out and moved (or just deleted) to other articles (again if relevant and critiical to those other subjects). I think the strip-move process will be easy with 'move to' targets always in the 'Talk Disucss' sections of related articles (for review and final movement into the related articles).
After seeing ego driven academia at OOPSLA in the 1980s/1990s try to redefine 'aggregation' and 'composition' WITHOUT using qualifiers (Object aggregation via containment vs functional aggregation via inheritance) I am very partial to any qualifiers (in the content) that you may take issue with AND HAVE RECOMMENDATIONS FOR. I think the current WikiPedia articles on 'Aggregation' and 'Composition' (vs inhertiance) should be renamed with 'Object Aggregation' and 'Object Composition'. The point being that NO ONE should start to redefine (and thus nullify) the English Langague and its (vital) semantics (so common in SOME academia types).
Regarding the function table thoughts above - Most language specifications for mechanisms result from an evolutionary recognition of prior programming practices. Command dispatcher patterns with function pointers in C during the 1980s comes to mind as a pre-cursor to the formal mechanisms of method based aspect of polymorphism. The article on Virtual Tables has (1) a mechanist and (2) function centric emphasis (as it should) that fulfills a polymorphic design intention. VI, on the other hand, is inherently a control mechanism for ALL polymorphic forms of code elements such as state space, delegates, etc. IMHO - In hardward design and simulation languages (I have about 5 years in this area) that use OO semantics need to distinguish VI as a control mechansim for event related polymorphism so central to parallel processing and simulation environments (behaviorals). So I recommend (for now) the VI non-mechanistic emphasis (of VI semantics) that should be backed up later with current use/prior use references.
Regarding your statement ...problems with multiple inheritance.. - There is no 'problem' with MI but there are really poor implementations (or NO implementations) in most major languages :-) Your excellent point however is well taken. This relates to the semantics of VI, II, MI, etc. as they relate to other articles in WikiPedia. This makes our joint mission even more critical to focus and minimize the VI article on VI and link to problems and related issues via topic map. To do this the (1) sematic aspects must be fully enmerated, (2) the semantic mechanisms of VI (and only VI) should be articulated as following from the semantics, (3) specific language spec mechanisms (C# VI in interfaces, etc Vs C++ VI, Java VI) should be shown as a subset or full implementation of VI SEMANTIC mechanisms. To help us in this we can just use enumerated lists of (A) semantic aspects, (b) semantic mechanism, (C) actual mechanism in lanagage spec/implementation approach. This should help in any dispute/analysis/improvement/rewrite/content-migration process that will complete the article.
Finally the Diamond problem (state space collisions) is poorly understood relative to its semantic solution (independent of any particluar language spec) which is very simple and easy (but not implemented in any major lanaguage spec that I know of). IF someone gets time such content needs to be focused onto the core WikiPedia article and not repeated here. This said I expect the full knowledge resolution process to take a matter of months to a good job as content migration (if any) and related content correlation need the input/advice/review of the other article authors. As such I'll put in some time now to 'get all the cards on the table' for us all the review.
As always thanks so much for you help and advice.
Shawnktalk—-Shawn wiki 13:33, 29 June 2006 (UTC)
PS. Of course, I will change all style stuff, like ALL CAPS to italics, etc after the 'cards on the table' phase. This way I focus on style/rewrite and flow while at the same time allowing others to review the content and ideas as you have done (so well I may add) in your above commments.
I still don't see how virtual inheritance, as it is used in this article, is different from virtual functions. I can see "virtual inheritance" being used to describe virtual functions, but it seems like the virtual function article covers that topic fully. —Ben FrantzDale 16:27, 29 June 2006 (UTC)
Good point!! In fact it tryed to clarify that issue in the first lines of article. Virtual inheritance includes ALL code elements, not just methods. So if C# introduces events, delegates, accessors, etc as code mechanisms it is entirely possible (if not inevitable) that later lanugages will standardize these code elements via inheritance. The control by parents (VI) or sharing by children (II) of ALL MECHANISMS is what I tryed to emphasize in the start of the article. I have to sign off for today but I'll create a section in this discussion on the semantic scope of Virtual Inheritance so we can focus all examples, history, references, external links to that aspect.
I was concerned (and still am) about exactly what you pointed out (which is..). This article does discuss virtual methods AS THE MOST COMMON MECHANISM but not THE ONLY MECHANISM for VI. I chose the 'virtual method' vehicle for the reason most are familar with it. I want to strip down the article as much as possible and still discuss (1) semantic aspects, (2) semantic mechanisms and (3) syntactic semantics. The Vtable article does not do this nor should it for the very reason you point out. To 'strip it down' I did not want examples, explantaions of VI for events (for example) or virtual inheritance of state space.
ALso did you compare the articulation in this article of control/polymorph mechanisms from their separation and articulation in the VTable article? Perhaps we should break out a section up front to clarify that VI is applicable to more than just methods??? Have to sign off for today but will return tomorrow. Shawnktalk—-Shawn wiki 18:50, 29 June 2006 (UTC)
PS. I know what your saying (we share the same concern) and I think I have a solution. Will post it tomorrow to see what you think.
Opened up [2-3] in the problem space. Interfaces, which exhibit VI as defined in this article, are a good example of the 'scope' of VI extending beyond functions. I'll put in a Problem_space [2-3] - Scope section to articulate as briefly as possible the concern you raised. We can hammer out the logical points there. If other points come up we can add them to the problem space.
Shawnktalk—-Shawn wiki 11:15, 30 June 2006 (UTC)
I completely agree with Ben here, and completely disagree with Shawn's version of this page. I also have many, many years worth of programming experience in many languages... *yet* that is all irrelevant, because this article is a gargantuan monstrosity that barely touches on the single topic that people are most often speaking of when they speak of Virtual Inheritance - that topic is Virtual Inheritance in C++, as in "class Foo : virtual public Bar".
Type "Virtual Inheritance" into any search engine if you don't believe me, and see how many results for turn up for the C++ diamond problem, as compared with results for C++ Virtual functions, or C#, or any other language.
I propose that, unless even a single person can be found who agrees with Shawn's convoluted view of Virtual Inheritance, that this article be stripped and reformatted to be far less cumbersome, less confusing and less eager to cover all of OOP. --202.164.194.254 11:11, 22 August 2006 (UTC)
I have removed the cleanup tag. Using the results of a google search Vs the ACM papers is an interesting justification for the defense of your positition (keyword definition of virtual inheritance). Please see the quotes at the bottom for the original papers forming the basis of OOP as well as various quotes from books in the 1990s. Finally open up a new section to defend your position from something more than google search hits. Please be historical and accurate in your view. Also I noticed you did not have a WikiPedia profile. Could you create this. Also, I note, Ben HAD THE OPPORTUNITY TO DISCUSS his position and failed to take it. Finally the code speaks for itself relativie to 'convoluted'. C# Interfaces ARE NOT SAME as C++ virtual methods (see use context). Why don't you explain that for all of us some terminology that isn't C++ only oriented.
The article length is only needed to show shallow thinking people what is in the code. There is no 'convolution' at all. Please discuss 'use context' of the 'virtual code elements' in your own words using other terminology if you feel you can be 'less convoluted'. Also discuss the difference in use context between C# interfaces and C++ virtual methods. Try to be as concise as the last two sentences to prove your 'convoluted' assersion. If, after all your experience, you can not discuss the phenonmena in the code examples (use context difference just mentioned) in a more concise format then you should open up your own article and show us all how much better you can define use context differences in virtual code elements.
Shawnktalk—-24.12.95.75 13:29, 1 September 2006 (UTC)
Here you go, Shawn. I've made an account so now you know whose name to type when you're really angry. This article is disputed. Not only by me, but also previously by Ben and another anonymous (maybe more as well - the discussion page needs archiving badly). I will be adding the tag because I still dispute it.
As an answer to your challenge: I don't need to give any quotes at all. That's not how this whole encyclopedia thing works. Facts aren't correct until proven incorrect. I don't need to prove it's not accurate and correct. The person writing the article needs to prove that it is accurate and correct. I don't feel you've done that. Your references are all offline. Give some online references that state that Virtual Methods have anything to do with Virtual Inheritance, or I will request arbitration for this article. Cite your content, and cite it with online content that is verifiable and even remotely relevant, or quit removing the cleanup tag and let people with decent communication skills have a go. --Mike Blackney 06:48, 6 September 2006 (UTC)

[edit] Intro Section - More Cleanup?

I'm sory, but I just don't follow even the first few lines of this article despite a degree in computer science and several years of work experience in C++. It says:

Virtual inheritance is a special form of inheritance in object-oriented programming languages.

Does this mean "a special form of function inheritance" or "a special form of object inheritance" or something else? It sounds like it's talking about virtual functions. It goes on:

It allows a parent to control code implemented in the children which inherit from it.

Does this mean it allows a parrent class to call code (functions) in a child class, or to actually alter functions in a child clas? It continues:

By using Virtual Inheritance any polymorphic functionality, within the parent, is moved into the children (functional dispersion), and then controlled (by the parent) along the lines of inheritance between parent and child (ancestor/descendent).

I'm sory, but I can't make heads or tails of this. Perhaps it is a language issue? Finally:

This is a 'language independent' definition not constrained by syntax semantics in specific computer languages like Eiffel, C++, C#, and Java. The term General Virtual Inheritance (GVI) should be used to qualify the language independent meaning relative to any alternate language specific meaning.

What is meant by "syntax semantics"? They are separate things. Is this saying that General Virtual Inheritance is just the use of virtual functions?


From Dictionary.com ...on 'semantics'
  • [1] Linguistics. The study or science of meaning in language.
  • [2] Linguistics. The study of relationships between signs and symbols and what they represent. Also called semasiology.
  • [3] The meaning or the interpretation of a word, sentence, or other language form: We're basically agreed; let's not quibble over semantics.
I did a google search on 'syntax semantics' and got 534000 hits.
Here is just a sample of relevant hits to the 'meaning' in Virutal Inheritance as defined in the this article.
Modeling Languages: Syntax, Semantics and all that Stuff (or ...Motivated by the
confusion surrounding the proper definition of complex modeling languages,
especially the UML, we discuss the distinction between syntax ...
citeseer.ist.psu.edu/harel04modeling.html - 21k - Cached - Similar pages
Four Concepts in Programming Language Description: Syntax ...In the linguistics
of both natural and computer languages, the terms syntax, semantics and
pragmatics are used to categorize descriptions of language ...
www.cs.sfu.ca/cs/people/Faculty/ Cameron/Teaching/383/syn-sem-prag-meta.html -
5k - Cached - Similar pages
------Microscosmic concerns of syntax ----
From the above source [B]:
Syntax, Semantics, and Pragmatics
..In computers, the semantic function of a programming language may be
considered to be embedded in the logic of a compiler or intepreter which
arranges for program execution. Of course, an equivalent semantic function,
albeit using a different representation, should also be found in the mind of the
programmer (we hope).
Syntactic semantics is a microcosmic approach to sytnax/semantic function/artifact production.
Computer languages differ from Human languages via the compiler/binary code generation process.
In the article 'syntax semantics' refers to the binary code generated from the source code.
The semantic function of the compiler (in the source above) is the subject of different
compilers, different CPUS, and how registers, pointer and other stuff must generate the
same 'meaning' of the syntax (I admit a very microcosmic approach from my hardware days :-)
The 'meaning' of OOL syntax is what the compiler generates.
------Macrocosmic software design process--------
In keeping with the more classic approach to Human linguistics would be from the source:
Introduction to A. P. Martinich, ed., The Philosophy of Language, Third Edition (Oxford University Press, 1996).
Syntax, Semantics, and PragmaticsOne way to see the difference between syntax, semantics, and pragmatics is to think about various kinds of linguistic deviance. ...
www.trinity.edu/cbrown/language/distinctions.html - 7k - Cached - Similar pages
From this source[C] :
  • [1] 'Syntax' is more or less synonymous with 'grammar'
  • [2] Semantics is the study of the meanings of linguistic expressions
  • [3] intension (what determines the extension of an expression; often regarded as a function from possible worlds to extensions)
  • [4] what a competent user of an expression must know
Item number four is the branch linking to computer artifact generation whereby the syntax has meaning
to the compiler to generate binary code, thus 'syntax semantics'.
------General clarity in article :-)---------------
Obviously there are many sources that address this but your concern is well taken in that the classic
Human lanaguage approach is what most of our industry (software programming) uses.
So in keeping with the 'pragmatic' approach (of the above source) we all want to article to be clear and non-confusing.
Therefore I changed the 'syntactic semantics' to 'syntax mechanism' to ensure a clear separation of concepts.
PLEASE, do not attempt to re-write anything as
I have to go through several passes to change some of the text to 'syntax mechanism'. Let me finish the changes
and reference work (over the next week).
Shawnktalk—-Shawn wiki 14:45, 8 July 2006 (UTC)
PS. Semantics is my forte and speciality but my only concern is that the article is accurate and definitive.
PS. Always remember that once the content is correct we can replace the core terms with any industry standard term.


Also, there is un-needed use of bold, there are lots of un-needed self refernce such as "Also see the Semantic Scope section below comparing language independent conceptual semantics with language specific syntax semantics.", and no citations. The "'See Also' topic map" makes it look like this article is trying to cover all of object-oriented programming rather than being concise. —Ben FrantzDale 17:02, 6 July 2006 (UTC)

Ben,
The focus of the See also section is to contrast VI to other inheritance phenomena via link.
I certainly do not intend to ..trying to cover all of object-oriented programming.. in the article.
Just writing it alone is more that enough work :-)
As for style, bold, links I'll cover these after the writing process is complete. So the article is still
in a clean up mode. If you read the other parts of discussion I'll bring in the citations after the clean up
and the article is done. Also if you read the other parts of the discussion the 'see also' section is currently
being used to cross reference (quickly) other articles. We want to 'spin this off' to some extent but for
now we're concentraing on the content. Please do not remove it for now as others are using it to help cross
reference some info.
It will take time but I'm sure we'll get there :-) In the end I feel confident the article content will pass
review concensus and all disputes. Thanks again for your input.
Shawnktalk—-Shawn wiki 13:50, 8 July 2006 (UTC)
Ben,
According to YOUR understanding where does the 'virtual' in 'Virtual Inheritance' come from?
Shawnktalk—-Shawn wiki 17:51, 7 July 2006 (UTC)
I'm not sure exactly why C++ decided to use virtual to deal with the multiple inheritance problem, but that's what they chose and that's the only thing I think when I hear "virtual inheritance". —Ben FrantzDale 05:32, 24 July 2006 (UTC)
I've been doing C++ projects for years and relate the 'virtual' to the virtual code element and not the keyword. Have you done any checks (search/read internet articles, etc) on what place the 'virtual code elements' have in other languages. A 'real world' code site is codeproject.com with over 3 million users and probably the best place to do a 'real world' sanity check. Have you looked at that site and scanned the content in articles?
Thanks much for your input and help.
Shawnktalk—-Shawn wiki 11:26, 24 July 2006 (UTC)

[edit] Anon comment

This article is pathetic and is exactly the problem with these OOP pseudo-programmers who try to make a science out of technical definitions. Good job dragging out a simple concept to 5 pages of bull without even taking the effort to make a diagram. As a computer scientist, I frown upon you OO design pattern people who throw buzzwords left and right but have no concrete accomplishments other than writing endless amounts of OOP books which clutter barnes and noble. User:24.40.132.93

Actually I'm a Sr. developer who has signifcant industry experience doing everything from supercomputers at Intel to Artificial Intelligent engines for IBM. I've worked for HP, ATT as well as startups. The length is there to show (and prove) the intro text. I do software and projects for a living.
If people understand the intro section (still not in final form by the way) then there is no need to look further.
After training, teaching and helping college hires, etc. the WikiPedia source is meant to be self standing and that is the reason for code examples. The previous code examples did not compile and did not show much.
So, ... are you saying that Virtual Inheritance is not about Virtual Code elements contained in a Virtual control mechanism, or are you a 'virtual' key word kind of guy who states that virtual inheritance is anything with the 'virtual' keyword infront of it? I think the content and concepts is the issue here, nothing else matters.

Shawnktalk—-Shawn wiki 11:37, 24 July 2006 (UTC)

You have a good point on the diagram issue. First I want to get this through dispute, concenses, citations and put in final references. After that I'd like a diagram myself but I'd like to get some input from others on that approach.
I also though about some tiny code examples in the intro/general section but links to examples are a cleaner approach to a stratified drill down solution.
Shawnktalk—-Shawn wiki 13:26, 25 July 2006 (UTC)


I'm a big fan of patterns; it took work experience with large-scale projects after a CS degree for me to fully understand them, but they aren't just BS and they are useful. That said, I tend to agree regarding the rest this article. I don't follow it at all; I'm trying to help sort it out. —Ben FrantzDale 05:32, 24 July 2006 (UTC)
Ben - Rewrote the intro and general - The article is pretty much ready for review - The intro and general sections cover all the key concepts in virtual inheritance. All concepts are demonstrated in the code (They are not just BS - see the code). Let me know what parts of the article thesis are your biggest problems (just the top three). I assume that coming up with three top items is good place to see where your concern is centered.
Shawnktalk—-Shawn wiki 17:06, 24 July 2006 (UTC)

[edit] More cleanup

I just re-added the cleanup tag. I am particularly dubious of the complete lack of citation and of the sheer length of the article. —Ben FrantzDale 05:52, 24 July 2006 (UTC)

Ben - I appreciate your efforts :-) But please hold off on the clean up tag for a few more days. I need do the final rewrite on a few sections. Thanks ahead of time for your patience and professionalism. In the mean time I do have some questions for you relative to the article.
[1] Do you have a problem with the language independence?
[2] Do you have a problem with the 'virtual code elements'?
[3] Do you maintain (in opposition to content) that anything with a virtual keyword is 'virtual inheritance'?
Thanks, again, for discussing the content.
PS - We can add the cleanup tag again later after discussing the content thesis and citations.
Shawnktalk—-Shawn wiki 11:48, 24 July 2006 (UTC)

[edit] Introduction

Ben - Always intended to do a final rewrite on the intro and general sections because some of it links to
sections in the article. Could you look through the new intro and general section??
I'll look throught your comments below Tuesday or Wednesday if I can't get to them tonight.


Shawnktalk—-Shawn wiki 17:02, 24 July 2006 (UTC)

I've said above that I can't follow the introduction. Let me pick that apart.

Virtual inheritance is a form of inheritance in object-oriented programming languages.

I agree.

It allows a parent to control code elements implemented in the children which inherit from it.

I've never seen the phrase "to control code elements" outside of this article. Alone this sentence sounds like a description of virtual functions.

--------shawnk response to Ben----------
  • Read these sections:
The control concept
The code
  • From the section - Control Mechanism Vs. Polymorphic Mechanism
The word 'control' means the code element may be callable (an abstract method),
assignable (a primitive data type) or both (an event). Whatever the
relationship (callable, assignable, etc) the parent 'controls' a 'virtual' code
element.
  • From the section - Use Context of Virtual Code Elements in C#
public
void Main_process()
{
Observer target_1 = new Observer("Number One");
Observer target_2 = new Observer("Number Two");
//
m_subject_ref.notification_targets += target_1.Notify_me; // Loadable virtual code element
m_subject_ref.notification_targets += target_2.Notify_me;
//
m_subject_ref.Notification_gate_flag = true; // Assignable virtual code element
m_subject_ref.Fire_event( "Event_1" );
m_subject_ref.Notification_gate_flag = false;
m_subject_ref.Fire_event( "Event_2" );
m_subject_ref.Notification_gate_flag = true;
m_subject_ref.Fire_event( "Event_3" );
}
}
  • From the section - Use Context of Virtual Code Elements in C#
Assignable State Space : In the example above the Main_process of the Observer_manager contains
the Notification_gate_flag code element which is an assignable code element (single value
assignment). The notification_targets code element is a loadable code element (multi-value
assignment).
In Virtual Inheritance code elements are said to be 'controllable'. This means that a code element can be called
(method), assigned (bool) or loaded (event). The conceptual semantics of the control aspect do not, and
should not, address the implementation details of a particular compiler or language. This control aspect is an
important difference between virtual inheritance and virtual functions (VTables - compiler implementation).
Shawnktalk—-Shawn wiki 12:34, 25 July 2006 (UTC)
-------shawnk response to Ben----------
Ben - Forgot to include the binding aspect - Also see:
language binding
  • From the section - Code Element Binding and Coupling
At the language level a code element may be called (method), assigned (primitive data type - single value
assignment) or loaded (event - multiple value assignment). At the binary level various 'under the cover'
operations are performed that connect the virtual code elements to their targets, sources and destinations.
Binary bindings are processor, operating system, and compiler dependent and are not addressed at the
language independent level used herein.
Thus the two aspects of binding (call, assignment, load, etc) and coupling (tight/loose) have important
implications on the use context of the virtual code element. Therefore virtual code element binding and
coupling, at the language level, are fundamental aspects of Virtual Inheritance (VI).
Shawnktalk—-Shawn wiki 14:17, 25 July 2006 (UTC)


By using Virtual Inheritance any polymorphic functionality, within the parent, is moved into the children (functional dispersion), and then controlled (by the parent) along the lines of inheritance between parent and child (ancestor/descendent).

I don't understand. I haven't heard the term "functional dispersion" elsewhere. Also, wouldn't static polymorphism count as "any polymorphic functionality" even though it isn't "virtual"?

-------shawnk response to Ben----------
Removed this so we could get to a intro we agree on.
On the static polymorphism - any form of polymorph is centric first to polymorphed units and second to some connection (bind, coupling) mechanism like inheritance, event binding, etc. So, even though I removed this paragraph you have a good point. In the new intro I tryed to put in a simple as possible factual statement that would get all readers familiar with VI on the same page - something we could all agree on.
So the intro is an aggrement page entailing and introducing the main thesis of the article. I tried to strip everything from the new intro that was detailed about VI. All the keywords and links are in the general section.
Shawnktalk—-Shawn wiki 12:17, 25 July 2006 (UTC)


This is a 'language independent' definition not constrained by syntax mechanisms in specific computer languages like Eiffel, C++, C#, and Java. The term General Virtual Inheritance (GVI) should be used to qualify the language independent meaning relative to any alternate language specific meaning.

Can you cite a source for "general virtual inheritance"? The Google hits I see are to this page. I agree that the language-independent menaing may be dealt with separately.

-------shawnk response to Ben---------
Removed paragraph - GVI keyword is now in general section - There is no reference for the term general virtual inheritance. The phrase, in the article, describes a 'virtual code element with a parent use context'. Do you have a another term to replace 'virtual code element with a parent use context' that can be abreiviated (GVI) for tagging to make the article readable. We can discuss this in a new section on key words used in the article if you like. Just list the keywords you have concerns with and state concern as (1) concept or (2) phrasing or both and we can 'pound them out together' :-)
Shawnktalk—-Shawn wiki 12:59, 25 July 2006 (UTC)
Unless qualified otherwise Virtual Inheritance (GVI) refers to the language independent meaning. Resolution Inheritance (RI) is the language independent meaning referring to state space collision resolution in the context of Multiple Implementation Inheritance (MII) of state.

Should this paragraph be preceeded by "Within the context of this article"? Also, "Resolution Inheritance" has its first Google hits on this page as well. I am dubious.

-------shawnk response to Ben----------
The 'within context of article' (a temporary line) has been removed along
with the paragraph. All the key words describe VI in the code examples.
The start of the C++ section discusses the resolution inheritance phrase.
Go ahead and do a search/replace on a PDF version and read whatever you
propose.
I wanted to do a quality article that focused on just the code and
virtual inheritance. I did not want another shallow, shoddy and regurgitated
example of so much of the junk on the Internet. I'll open a section on
this in the discussion this week.
I especially designed a stratified article that allows one to go as deep as
needed with some real code examples, not some worthless syntax example
that had no content relevant to the phenomena.
Lets pound out the intro on this one and then move on the general section.
Thanks again, Ben, for your work on this. I am sure that after we review
the (1) code/phenomena, (2) phrasing and (3) article partitioning/stratification
we can cover the (4) citations and references. The citations I have do
cover the phenomena but may use different phrasing. Again, try a substitute
and replace. I want to see what others come up with to harden out a good
solution to the concerns you mention.
Shawnktalk—-Shawn wiki 12:59, 25 July 2006 (UTC)


Also see the Semantics section which addresses the conceptual scope of Virtual Inheritance syntax mechanisms.

I'm dubious of this level of self-reference, especially in an article without citations. I tend think that the article is too long if users must be directed to specific portions of it. —Ben FrantzDale 12:57, 24 July 2006 (UTC)

Ben - The first majority of links are drill down or navigation links. This allows a quick descent to the code examples for the phenomena mentioned at the higher layers of the text. The second majority of links are to relevant WikiPedia articles on related material.
Shawnktalk—-Shawn wiki 05:27, 27 July 2006 (UTC)


Ben - Appreciate your input as always. You are more than welcome to re-write the article after I'm done with it. I am more concerned about accuracy of phenomena than terms. I'm re-writing the intro and general sections as we speak (have not ready through your input above but look forward to doing so). I did note in a breif look at the above about sefl-reference. Much of the terms I am using are 'baggage free' that SHOULD not show up anywhere but explain EXACTLY what the code does. I look forward to your replacing them with some 'baggage free' terms that will work and not change the meaning about what happens in the code.
If you are glutton for punishment :-) you can do a rewrite but if you start to remove key concepts that are there specifically to resolve controversy then we come to the point of the article.
Two camps exist - Virtual keyword or Virtual phenomena (this is simplification)? Language independence or just C++? Do these things exist (VCM, use context) and if so what do we call them? After the intro/general rewrite we (the WikiPedia community) should be ready to really rip the article apart. My attitude is really matter of fact bcause I want to see the controversy addressed and solved. This is what WikiPedia is all about. Merciless editing of content :-)
Will look over your input above in detail as soon as I update the intro/general. Will respond more fully then.
Thanks again for your professionalism :-)
Shawnktalk—-Shawn wiki 13:21, 25 July 2006 (UTC)

[edit] WikiPedia C++ project status

This article is an article about virtual inheritance in object-oriented languages.

The author (me) did not put this 'C++' project tag here.

I trust, Ben, that when you put that tag in here you are not trying to force the article to be only a C++ article but, rather, the C++ section should be reviewed by the WikiPedia C++ community (an excellent idea :-)

Please confirm that above is the correct meaning of the 'tag' for the C++ project.

By the way: I Love C++. It is my preferred language because of MII. I love C# as well but hope for a language in the future that will combine the best of both languages :-)

Shawnktalk—-Shawn wiki 13:21, 25 July 2006 (UTC)


[edit] Logical spectrum of article via keyword/keyphrase counts

The article keyword/keyphrase count (and keywords/key phrase) is listed below. Generating a PDF version of the article and doing a search via Adobe PDF reader version 7 is a good way to quickly find the keywords and how they are used in the article

These counts are from the July 26 2006 version of the article.

These counts are useful to content comparison/replication in other articles dealing with object-oriented language inheritance phenomena.

Some of the words below are not keywords/key phrases but are highly relevant to accurate articulation of the subject matter. They are included to help in comparative analysis of other articles.

Running the same pattern over the C++, C# and Java language specification shows the article (WikiPedia VI article) makes very few assumptions when compared to a formal ISO language spec (as it should as a reference document Vs. an architecture/spec doc).

Note the logical spectrum gives an accurate breakdown of what the core focus of the article is. The same table can be resorted (mannually of course) based on highest count first. This is done at the bottom to show the top dozen logical keys in the content.

  • 010 - keyword
  • 042 - phenomena
  • ---------
  • 252 - inheritance
  • 001 - class inheritance phenomena
  • 150 - virtual inheritance
  • 007 - virtual inheritance phenomena
  • 028 - (VI)
  • ---------
  • 011 - general virtual inheritance
  • 015 - (GVI)
  • 009 - simple virtual inheritance
  • 015 - (SVI)
  • ---------
  • 002 - implementation inheritance phenomena
  • 028 - implementation inheritance
  • 010 - (II)
  • ---------
  • 169 - code element
  • 012 - implementation code element
  • 099 - virtual code element
  • ---------
  • 094 - use context
  • 004 - use context aspect
  • ---------
  • 008 - virtual keyword
  • 020 - virtual control mechanism
  • 012 - (VCM)
  • ---------
  • 006 - diamond problem
  • 001 - inherited class ambiguity
  • 005 - (ICA)
  • 001 - method override ambiguity
  • 001 - (MOA)
  • 011 - resolution inheritance
  • ---------
  • 015 - binding
  • 005 - element binding
  • 002 - language binding
  • ---------
  • 007 - coupling
  • 001 - element coupling
  • 002 - language coupling
  • ---------
  • 037 - aspect
  • 006 - control aspect
  • 001 - specification aspect
  • 003 - polymorphic aspect
  • 004 - use context aspect
  • ---------
  • 006 - semantic
  • 011 - semantics
  • 001 - semantic aspect
  • 007 - conceptual semantics
  • ---------
  • 003 - syntax
  • 002 - syntax mechanism
  • ---------
  • 042 - mechanism
  • 001 - resolution mechanism
  • 026 - control mechanism
  • 001 - binding mechanism
  • 004 - specification mechanism
  • 002 - pattern mechanism
  • ---------
  • 071 - pattern
  • 013 - pattern unit
  • 002 - pattern unit mechanism
  • 009 - SPD pattern
  • 002 - functional pattern
  • 001 - design pattern
  • 001 - performance pattern

High count list - first 12 counts

  • 252 - inheritance
  • 169 - code element
  • 150 - virtual inheritance
  • 099 - virtual code element
  • 094 - use context
  • 071 - pattern
  • 042 - phenomena
  • 042 - mechanism
  • 037 - aspect
  • 028 - (VI)
  • 028 - implementation inheritance
  • 026 - control mechanism


[edit] Virtual Inheritance article ready for your review

Ben, haven't heard from you to discuss the code/core phenomena.

Also some of the other disputants have not replied or answered in this discussion. I take that to mean they are satisfied with any current imperfections in the article and will let it ride.

As always I look forward to any critique to improve the article.

Went ahead and put in the reference list and quotations.

Article is ready for final review and dispute (except for one diagram to put in fall 2006 - see below).

Please review when you get time.

All code and phenomena is intact. Researchers should not have to go anywhere else but can copy and paste from the article on any aspect of Virtual Inheritance (hopefully).

The drill down stratified approach should allow most to review the intro and not go further if they are already familiar with the subject.

At the same time high school aged programmers should also be able to drill down and navigate quickly to understand the core concepts.

Anon had a good recommendation on a chart or diagram which I would like to do but I want the current article to ride for a few weeks or months before doing so.

I expect that when the college fall session starts we should get more traffic and comment on the article. (Summer is always lazy and laid back :-)

Please review the next-to-final version (will add a good diagram this fall) of this article when you get time (end of July 2006).

I still have some other WikiPedia articles to finish before I get back to the diagram for this article.

Have about 10 times more references and quotes than in the article but to minimize article (and still keep a self standing reference quality) I only put in the basic stuff.

I hope I have answered your questions and concerns on links, references, etc.

I have done a pretty good research search on alternate terminology AND historical terminology (none of which is in the article) in the worlds best research knowledge bases, services. Hopefully you can replicate this at your college.

See the article keyword list at the top of the article.

Please try to do a substitute and replace prior to recommending any alternate terms. Please also site referential history and citations of prior use. My history goes back to inception point (see quotations) and many other key articles from the 1960s time period.

Be especially articulate on alternate terms as to WHY you think they are better (especially citations and standard industry use).

Because of Blogs, personal opinion (forums) and quickie articles over 99 % of Google searches are either inaccurate or not usable (when compared to research databases, services, etc) in patent level work.

To the best of my understanding the article is now up to that standard level (all style issues aside).

Please let me know what you find in your research.

shawnk - author

Shawnktalk—-Shawn wiki 17:01, 28 July 2006 (UTC)

[edit] Article Hard to Follow

Response by user (author)

Shawnktalk—-Shawn wiki 15:18, 30 July 2006 (UTC)

to user:

—Ben FrantzDale

Ben, your comment '...I don't follow it at all..' (see above in this discussion) concerns me as I thought the article was pretty clear on 'virtual code elements' and 'use context'. Also I felt that 'implementation code elements' is a pretty good contrast to show the virtual/implementation concepts so fundamental to Object-Oriented Programming (OOP).

In my concern, and to ensure others could 'follow' the article I put in the quotation section to relieve other readers of replicating some of the research to the article.

The last line of the article is key and centric to 'virtual code elements'. These quotations are from the programmers who developed the object-oriented language paradigm.

I think if you just go to the last line (of the article) and read it several times you could 'follow' the main thesis of the article (virtual inheritance). If you still have a problem following the article you may try to read all of the quotes and 'connect the dots' (so to speak) for the (Eureka statement)

  • '...foundation for a completely new language approach..'

If the article is still 'hard to follow' I added the 'External Links section' with a link to the ACM site. This should make it easier for you (and others) to validate the content and thesis. If you are a member (of ACM) you should be able to research the paper (online) and review the context of the quotations.

The reference;

  • [5] Nygaard, Dahl, (Wexelblat) : History of programming languages, Academic Press 1981

is considered by many to be the definitive paper on the history of the object-oriented programming paradigm.

The 'eureka' statement (see quotations section) is a good place to start (in the paper) to see how virtual inheritance (as defined in this article) was a key concept right from the inception point of OOP.

Also the reference;

  • [03] Martin, Odell - 1993 : Object Orientation

is indicative of the mid 1980s OOP maturity in which many (of these publications) have a succinct definition of virtual inheritance which agrees (rightly so) with the founding concepts in reference [5].

If you still have a problem following the article you may wish to review reference [3] and reference [6].

Even after all of this, if the article is still 'hard to follow' and you want to '..help sort it out..' please let me know of your recommendations :-)

Your input has been very helpful in making the article better for others who may find virtual inheritance (as described in this article) 'hard to follow'. Although the current article has imperfections I trust they do not detract significantly from the article thesis and, currently, it is 'easier to follow' now that the article is in the 'next to final form'.

As mentioned elsewhere (in this discussion) I will try and do a good, simple diagram from one of the code examples but I need to complete some other WikiPedia articles first.

Hopefully, after the diagram, the article will be understandable and 'easy to follow' for even high school level students, so important to the continuation of our industry.

I always look forward to your professionalism and help. Thank you again for your input.

Shawnktalk—-Shawn wiki 15:18, 30 July 2006 (UTC)

Retrieved from "http://en.wikipedia.org../../../v/i/r/Talk%7EVirtual_inheritance_05d4.html"