Talk:Virtual inheritance/Archive 1

This is an archive of past discussions about Virtual inheritance. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Last paragraph

The last paragraph is definitely not NPOV, especially since the first person is used.Gregsinclair 20:27, 31 May 2007 (UTC)

agreed it should be removed and placed here in discussion - also the issue raised does not impinge on the correctness of the discussion.

the issue looks to be a compiler specific bug in its handling of the layout of the vtables pointers, a result of having no real data members in the class to seperate the classes. ie the same vtable location is being set twice or written over twice by each of the derived class constructors perhaps? it would be interesting if the writer would name the compiler. it is an interesting find however. -- anon

— Preceding unsigned comment added by 124.187.244.117 (talk) 20:52, 9 June 2007 (UTC)

More stuff

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).

Shawnk^talk—-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 :-)

Shawnk^talk—-Shawn wiki 16:38, 14 November 2006 (UTC)

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).

Shawnk^talk—-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???

Shawnk^talk—-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.

Shawnk^talk—-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 :-)

Shawnk^talk—-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.

Shawnk^talk—-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.

Shawnk^talk—-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.

Shawnk^talk—-Shawn wiki 13:46, 23 October 2006 (UTC)

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.

Shawnk^talk—-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.

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

Shawnk^talk—-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.

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].

Shawnk^talk—-Shawn wiki 17:30, 1 July 2006 (UTC)

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.

Shawnk^talk—-Shawn wiki 18:19, 1 July 2006 (UTC)

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.

Shawnk^talk—-Shawn wiki 13:50, 6 July 2006 (UTC)

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).

Shawnk^talk—-Shawn wiki 17:09, 1 July 2006 (UTC)

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.

Shawnk^talk—-Shawn wiki 18:53, 1 July 2006 (UTC)

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).

Shawnk^talk—-Shawn wiki 17:09, 1 July 2006 (UTC)

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.

Shawnk^talk—-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.

Shawnk^talk—-24.12.95.75 13:41, 30 June 2006 (UTC)

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).

Shawnk^talk—-Shawn wiki 17:09, 1 July 2006 (UTC)

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 :-)

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 :-)

Shawnk^talk—-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.

Shawnk^talk—-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.

Shawnk^talk—-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.

Shawnk^talk—-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.

Shawnk^talk—-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.

Shawnk^talk—-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:

Link to article you mention on Inheritance

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

Shawnk^talk—-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.

Semantics

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.

Shawnk^talk—-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)

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:

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?
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?
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"?
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)

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 :-)

Shawnk^talk—-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.

Shawnk^talk—-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. Shawnk^talk—-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.

Shawnk^talk—-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.

Shawnk^talk—-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)

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.

[A] http://citeseer.ist.psu.edu/harel04modeling.html

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

[B] http://www.cs.sfu.ca/cs/people/Faculty/Cameron/Teaching/383/syn-sem-prag-meta.html

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).

[C] http://www.trinity.edu/cbrown/language/distinctions.html

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).

Shawnk^talk—-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.

Shawnk^talk—-Shawn wiki 13:50, 8 July 2006 (UTC)

Ben,

According to YOUR understanding where does the 'virtual' in 'Virtual Inheritance' come from?

Shawnk^talk—-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.

Shawnk^talk—-Shawn wiki 11:26, 24 July 2006 (UTC)