Inheritance semantics

From Wikipedia, the free encyclopedia

This article or section may contain original research or unattributed claims.
Please help Wikipedia by adding references. See the talk page for details.

This article or section does not adequately cite its references or sources.
Please help improve this article by adding citations to reliable sources. (help, get involved!)
This article has been tagged since October 2006.

This article may require cleanup to meet Wikipedia's quality standards.
Please discuss this issue on the talk page or replace this tag with a more specific message.
This article has been tagged since December 2006.

This article reads like a personal reflection or essay and may require cleanup.
Please improve this article by rewriting this article in an encyclopedic style. (documentation, talk)

The neutrality of this article is disputed.
Please see the discussion on the talk page.

In computer science, inheritance semantics is the study and development of terminology describing the phenomena of inheritance in the context of object-oriented computing languages. The study and development of this branch of semantics is relevant to software patents and technical documentation. It is also relevant to articulating and enumerating object-oriented inheritance.

1 General
- 1.1 Semantic scope
- 1.2 Functions Vs. Functionality
2 See also

[edit] General

It is necessary for the terminology of object-oriented (OO) computing to articulate the phenomena of Inheritance precisely. The terminology should reflect the conceptual semantics of the core computing phenomena rather than the syntactic mechanisms of any one object-oriented language.

Ideally the conceptual semantics and syntax mechanisms of OO code elements are identical but this is not always the case. The rapid evolution of computer science has accelerated the semantic evolution of its core terminology.

It has become a common industry practice, therefore, to provide qualifiers and acronyms (if needed) for terms that vary in their conceptual meaning due to use in a specific context (generally a particular computer language syntax).

In Implementation inheritance (II), for example, there is

MII (Multiple Implementation Inheritance)
SII (Single Implementation Inheritance)
MI - SII plus Interfaces

Note that MI (Multiple Inheritance) can technically include Interfaces as in C#. Thus the impetus to clarify the conceptual semantics of core terminology in the face of industrial obsolescence.

A case in point (of precise articulation) in Virtual Inheritance is General Virtual Inheritance (GVI) as distinguished from Simple Virtual Inheritance (SVI). The difference due to 'use context' in GVI and SVI is an important and fundamental distinction between abstract base classes and interfaces. To equate interfaces with abstract base classes (GVI) is incorrect because interfaces (SVI) do not provide a parental use context.

The articulation of 'use context' as fundamental to virtual inheritance is a good example of 'inheritance semantics'. The common industry practice of using 'acronym qualifiers' (as above) helps to ensure the meaning (the semantics) describing phenomena is clear.

To better articulate the different phenomena of Inheritance the conceptual semantic scope of object-oriented language and syntactic mechanisms is briefly addressed below.

[edit] Semantic scope

When discussing any form of object-oriented (OO) inheritance it is important to distinguish the syntactic mechanisms of a particular language syntax from the language independent conceptual semantics of computing logic phenomena (i.e. the actual functionality).

This allows discussion of future and hypothetical object-oriented computer languages as well as past and current languages in terms of inheritance phenomena such as Virtual Inheritance (VI) and Implementation Inheritance (II).

A language independent semantic scope allows the discussion of concepts of common phenomena across different computer languages and computing machines. Historically this process has NOT always been easy for the following reasons.

Syntax as concept : A common confusion is to present the syntax mechanisms

of a particular language as a general phenomena for all languages. Although

this can often be done (x = 1 + 2), there are many exceptions. In such cases it

is important to qualify the conceptual semantics of general computing phenomena

(boolean logic) from the syntactic mechanisms of a particular language.

Reversed Causality : Another common confusion is the reversed causality of

design intention (human thought) and design implementation (binary code). This

occurs when someone trys to present the syntactic mechanisms of an

implementation (binary code) as the conceptual semantics of the original design

intention (thus reversing causality).

Because of this confusion it is important to distinguish the language independent nature of inheritance phenomena from the syntactic mechanisms of any particular language.

For example, in object-oriented Virtual Inheritance (VI), C# interfaces can not 'replace' the functionality of C++ abstract methods. C# Interfaces are not the same as C ++ abstract methods because the use context of the virtual code elements are different. The language independent concepts of virtual code elements and use context allow the semantic comparison of C# interfaces and C++ abstract languages to be stated concisely and correctly. Without a language independent semantic scope such comparisons can not be discussed.

The following semantic stratification (layered structure) helps to highlight the fundamental difference between syntax mechanisms (in computer languages) and conceptual semantics (in Human thought).

Semantic Stratification of the Software Design Process
Process Layer	Linguistic Context	Process Context	Process Step	Process Result
Level 3	Phenomena	Logic	of Implementation	Binary code
Level 2	Language	Syntax	of Specification	Source code
Level 1	Concept	Semantic Aspect	of Intention	Human Thought

The table above shows how the original meaning (intention) in the mind of the software programmer becomes an implementation in binary code. The meaning must flow through each layer of the process.

In the program compilation process, for example, a compiler 'bug' can exist when the syntax is compiled and produces incorrect logic in the binary code. In this case the meaning of the syntax was NOT expressed in the binary code. This is an error of translation from source code (layer 2) to binary code (layer 3).

In the software design process the programmer's intention becomes a specification, which becomes an implementation. This self-evident cause-effect relationship is presented in the table above.

The key point of leveling the semantics (as above) is to show that BOTH a spatial aspect (stratification) and temporal aspect (sequential) exist in computer language semantics.

The spatial aspect layers the 'foundation' of software design intention as a basis for design specification and design implementation. This is relevant to the common confusion of syntax as concept.

The temporal aspect sequences the cause-effect relationship (in time) so that Intention (Human thought) precedes specification (source code) and implementation (binary code). This self-evident fact is relevant to the common confusion of reversed causality.

The table above helps to articulate the nature of common confusions in the semantic scope of language independent inheritance phenomena.

For instance, in the comparative example above (C# Interfaces Vs. C++ abstract methods) a language independent semantic scope exists conceptually (at level 1) to compare language features (interfaces/abstract methods - in level 2) in a correct and concise manner.

It is self-evident that the scope of inheritance semantics are always language independent.

[edit] Functions Vs. Functionality

When discussing object-oriented inheritance the term 'functional' and 'functionality' should not be confused with the term 'function' (as in a object-oriented class method).

During the object-oriented design process a software designer can 'move' functionality along the lines of inheritance. An example is moving a commonly used state variable (int, bool, etc) to a base class where it can be shared among the derived classes.

Movement of code elements and software expressions along lines of inheritance is a phenomena of object-oriented 'functional design'. It is important to note, therefore, that inheritance encompasses ALL kinds of code elements, not just methods (functions). Inheritance based functional migration, normalization, aggregation and dispersion are phenomena inclusive of ALL CODE ELEMENTS in a language (not just methods).

For example, in General Virtual Inheritance (GVI) the intentional partitioning (via design) of functionality is inclusive of structures, fields, and primitive data types (i.e. all kinds of code elements). This 'inclusive' aspect of virtual inheritance is in keeping with the 'general' nature of GVI to encompass the broadest range of possibilities (for the code elements controlled via GFI in any particular object-oriented language). This, in turn, re-emphasizes the scope of GVI as a superset of VTables and virtual functions.

Although methods (functions) are an important code element in object-oriented Inheritance they are not the only part. Thus the liberal use of 'functional' and 'functionality' in the definition of Virtual Inheritance (VI). The term 'functionality' is used to indicate the inclusive nature of VI relative to ALL FORMS of code elements (methods, variables, structures, events, etc.) which can be virtually inherited.

Thus, in object oriented inheritance, functionality can be inherited from base classes by derived classes using either virtual or implementation inheritance. The inherited functionality is a set of code elements such as methods and state variables that make up the inherited functionality.

[edit] See also

This 'See Also' topic map provides links to articles related to object-oriented inheritance.

Fundamental inheritance phenomena is documented in the articles below. Also, class Inheritance (CI) is best understood in the context of other design approaches (for combining computing functionality), issues and problems in software architecture.

The sections listed below help to distinguish the concepts of 'functional dispersion/aggregation along lines of inheritance' (as in Virtual/Implementation Inheritance) from 'object aggregation/composition' as embedded/referential members in a class (embedded/referential containment).

Note the interesting semantic distinction between the AGGREGATION of 'self reliant' objects from the COMPOSITION of 'object parts' (from the English language - 'composition' semantics infers 'composed of parts').

Similar subtle but important distinctions (semantic aspects) exist between virtual, implementation, multiple (MII) and interface inheritance.

[edit] Semantics

[edit] Fundamental Inheritance Concepts

This section contains links to articles relevant to the general concept of inheritance.

[edit] Detailed Inheritance Concepts

This section contains links to articles explaining the conceptual details of inheritance.

[edit] Other Design Approaches

This section contains links to other ways of combining computing functionality (object aggregation/composition). Links to these concepts are listed to contrast inheritance from other approaches to functional design in object-oriented languages.

[edit] Inheritance Issues and Problems

Many design problems in inheritance occur not because a mechanism (VI, II, MI, Interface) is 'bad' but because the right tool (mechanism) wasn't used for the right job (like using a hammer for a screwdriver). The problems below are not inherent to semantic mechanisms (which define the MEANING of a language specification). These problems ARE, however, inherent to poor software design (actual language mechanism misuse in Java, C#, C++ etc.) or poor language implementations (bad compiler architecture/language specification/language design).

Note that the semantics of a poorly designed 'expression mechanism IMPLEMENTATION' (in a language specification or design) do not 'redefine' the SEMANTICS of an expression mechanism (the inherent semantic meaning across all past, present, future and hypothetical language specifications). The 'CONCEPTUAL expression semantics' exist prior to and beyond any one language SYNTAX specification (C++, C#, Java, etc.). Most language mechanism specifications (SYNTAX EXPRESSIONS) are formalizations of previous programming practices in an earlier language (thus an evolution in expression formalization and understanding).

Note also that syntax mechanisms should not be confused with conceptual semantics. You can not take a specific language specification and reverse engineer its syntactic mechanisms (what the compiler SHOULD generate) into the conceptual semantics expressed in the English (Human) language.

The supposition that inherently difficult and complex processing should suddenly become simple and trivial is also incorrect (i.e. an automobile is NOT as complex as a nut and bolt).

In the same way, each inheritance mechanism (VI, II, MII, etc) has logical semantic aspects that pre-exist ANY particular language implementation generated by a compiler (cause/semantics precedes effect/implementation). This perspective is important in distinguishing a poor software design (expression mechanism misuse) from a poor mechanism specification/implementation (language specification problem, compiler design problem).

[edit] Design Intentions in Inheritance

Virtual Inheritance (VI) is one of many object-oriented mechanisms used to achieve a design intention. Object-oriented software design intentions are generally guided by the principles listed below.

[edit] Functional Normalization

Functional normalization is the removal of needlessly replicated code. This section contains links to articles related to concepts relevant to this process.

Functional normalization (object-oriented programming)
Orthogonalization (mathematical normalization)
Aspect (functional perspectives orthogonal to core concern)
Core Concern (the intrinsic and inherent core functionality of a class)
Cross-cutting Concern (common functionality orthogonal to core concern)
Refactoring (restructuring software)
Database Normalization (minimize needlessly replicated data)

[edit] Logical Context of Inheritance Semantics

Inheritance semantics may be categorized and classified under the following headings.

Retrieved from "http://en.wikipedia.org../../../i/n/h/Inheritance_semantics.html"