I wrote up a little program that generates C++ from a simple input
format, a list of relations. Basically I'm trying to understand
"composition hierarchy" vis-a-vis "inheritance hierarchy."

The inheritance hierarchy has a mechanism in C++ to describe it, class
inheritance, but there doesn't seem to be built-in support for
composition hierarchy. That's no exactly so, but to iterate over the
contained elements of a class requires the implementation of an
iterator, and for nested composition as a tree, depth or breadth first
iterators or iterators to given depths or heights.

So I began with simply a tree to represent a composition hierarchy, then
got to having each node (class type) having as well a list of child
elements to represent inheritance hierarchy, then got to having multiple
parents in the tree for inheritance, and then also there could be
multiple parents in composition, along the lines of different uses of
the objects.

Part of the notion is to automatically generate methods conforming to
interface or convention for standard library interaction. For example,
there might be interfaces implemented for comparable and then
ostreamable, where ostreamable would implement simple ostream inserters
by iterating over the containment hierarchy.

Implementing istreamable for istream extractors is a little more
involved, in terms of notions like parseable, recognizeable, and
rejectable in terms of acceptable, towards having a decomposable parser,
decomposed into each class having its own implementation, then composed
in the composition hierarchy, probably using parser expression grammars,
and conceivably specialized in the composite classes.

This is a circuitous route towards implementation of a statistics
gathering parser, or rather, statistics gathering over the composition
hierarchy. Besides automatically generating a composition hierarchy and
inheritance hierarchy off of a terse specification, I also want there to
be generated a variety of statistics, where basically all these object
types represent data embodied in some form. The statistics are
variables for input into statistical inference algorithms.

Anyways for now in implementing this little code generator, where in
terms of the upwards and downwards composition and hierarchy trees from
each node, each type, with each link having various attributes, then
that is all in terms of class composition and inheritance, using only
the type names, at some point I have to enumerate methods and
implementations, besides deconstructing the implementations towards
algorithmic recomposition of the algorithms, the attributes get
arbitrary. There isn't a convenient dynamic mixin facility in C++,
which would be convenient. So, I need to figure out more about the
attributes of inheritance and composition relations.

Anyways I wonder if there are some examples of generating iterators over
a composition/containment/aggregation hierarchy. This is about typing
each element contained in a composition hierarchy to provide iterators
over its elements, then it could very easily be treated as a tree in
graph algorithms, in an automated manner.

So: inheritance hierarchy, use built-in inheritance mechanism and
generally use pointers to allow polymorphism. Composition hierarchy,
good practice?

Thanks,

Ross F.

Ross A. Finlayson a écrit :
>
> I wrote up a little program that generates C++ from a simple input
> format, a list of relations. Basically I'm trying to understand
> "composition hierarchy" vis-a-vis "inheritance hierarchy."

The usual question is between composition and *private* inheritance.
For that particular question, see the FAQ:
http://www.parashift.com/c++-faq-lit....html#faq-24.3
or (seeing some french in your question):
http://jlecomte.ifrance.com/c++/c++-...itance-fr.html

> [problem statement]

I could not understand what you want to achieve, I suppose you have a
polytree represnting a hierarchy of concepts like
streamable...(shouldn't they be orthogonal ?) and interfaces.
And from a description language, you want to add nodes in this tree and
finally generate classes used for statistical analysis.

And I don't see the relation with the problem that follow.

>
> Anyways I wonder if there are some examples of generating iterators over
> a composition/containment/aggregation hierarchy. This is about typing
> each element contained in a composition hierarchy to provide iterators
> over its elements, then it could very easily be treated as a tree in
> graph algorithms, in an automated manner.

If think Loki gives some examples of iterators with different
strategies. I think Boost.Graph should have something to add too.

> So: inheritance hierarchy, use built-in inheritance mechanism and
> generally use pointers to allow polymorphism. Composition hierarchy,
> good practice?

That depends on what you want to achieve (surely part of what I did not
understand earlier in your post).
Good practice is :
- public inheritance is a "IS A" relation-ship
- composition and private inheritance are a "HAS A" relationship.
So I would say that for concepts such as streamable, public inheritance
is the relevant choice (especially since you want to handle the objects
isomorphically) but for attributes, composition is more likely to be the
good choice.

Michael

Michael DOUBEZ wrote:
> Ross A. Finlayson a écrit :
>>
>> I wrote up a little program that generates C++ from a simple input
>> format, a list of relations. Basically I'm trying to understand
>> "composition hierarchy" vis-a-vis "inheritance hierarchy."
>
> The usual question is between composition and *private* inheritance.
> For that particular question, see the FAQ:
> http://www.parashift.com/c++-faq-lit....html#faq-24.3
> or (seeing some french in your question):
> http://jlecomte.ifrance.com/c++/c++-...itance-fr.html
>
>> [problem statement]
>
> I could not understand what you want to achieve, I suppose you have a
> polytree represnting a hierarchy of concepts like
> streamable...(shouldn't they be orthogonal ?) and interfaces.
> And from a description language, you want to add nodes in this tree and
> finally generate classes used for statistical analysis.
>
> And I don't see the relation with the problem that follow.
>
>>
>> Anyways I wonder if there are some examples of generating iterators
>> over a composition/containment/aggregation hierarchy. This is about
>> typing each element contained in a composition hierarchy to provide
>> iterators over its elements, then it could very easily be treated as a
>> tree in graph algorithms, in an automated manner.
>
> If think Loki gives some examples of iterators with different
> strategies. I think Boost.Graph should have something to add too.
>
>> So: inheritance hierarchy, use built-in inheritance mechanism and
>> generally use pointers to allow polymorphism. Composition hierarchy,
>> good practice?
>
> That depends on what you want to achieve (surely part of what I did not
> understand earlier in your post).
> Good practice is :
> - public inheritance is a "IS A" relation-ship
> - composition and private inheritance are a "HAS A" relationship.
> So I would say that for concepts such as streamable, public inheritance
> is the relevant choice (especially since you want to handle the objects
> isomorphically) but for attributes, composition is more likely to be the
> good choice.
>
> Michael

Thank you. I am just trying to learn a way to maintain a database, in a
composable manner. The mention of polytree seems useful, that seems to
describe the combination of upwards and downwards inheritance and
composition hierarchy. Yet, in consideration of the node of that kind
of polytree itself, it contains references to four different sequences
of the same types, it is an irregular type, so if it had a composition
relation with itself then it would be cyclic.

class node{
vector<node*, attribute*> composition_children; // <- this type is
composed of these elements
vector<node*, attribute*> inheritance_parents; // <- this type inherits
from these classes
vector<node*, attribute*> inheritance_children; // <- these types
inherit from this type
vector<node*, attribute*> composition_parents; // <- these types are
composed of this type

type m_identifier; // <- this is the type
};

As a graph, each node, attribute pair indicates an edge from node to
node. A simple specification of a node's composition might be along the
lines of

node = (node attribute)+ (node attribute)+ (node attribute)+ (node
attribute)+

That isn't enough specification to indicate proper identifiers for the
members for their semantic meaning, in trying to indicate what be
graphically meaningful iterators over the composed elements, in terms of
their meaning.

While that may be so it's very useful for a regular composition
hierarchy, which holds true for many data types. So, there might be
interfaces defined for constructable, creatable, cloneable; comaparable;
stringable, ostreamable, where the interfaces indicated would have code
generated for them, that might be listed in the inheritance listing for
dynamic casting up to those types, or simply generated blind to match
convention, eg "Big 3", orthogonal interfaces and also extensions of
them. I'm interested in implementing something along the lines of an
istreamable interface, as a convenience for acceptable, which is
parsable and so on, in terms of something like boost's "spirit" which
has an interesting composable parser system, or in terms of parser
expression grammar (PEG) or so. Yet, while there might be a native
encoding for a type so that it would be reasonable there to encapsulate
the parser for that type within the object or a nested hierarchy, there
are many data types that would vary /sequences in their parsing.

Anyways in terms of the statistics, to each of the objects in the
composition hierarchy there is going to be attached a "statistical"
object, where the relation among those will match the relation among the
composition and inheritance hierarchy, eg, the statistics for an
instance would be the root of trees out through the parents and children
in inheritance and composition. Those would often be scalar (or
algebraically composite) values like reals or complex numbers, or more
often counts, integers counts, in enumerated types discrete statistics,
and would simply be the lowest/atomic/elementary compositional types.
They could be counts or measures over natural language constructs. In
inherited types, specialized subtypes with the same compositional role,
they would have both the default statistics, and also possible
specialized statistics. Then, there is some consideration of developing
statistics over ad hoc series, that is about taking a sequence of
objects, besides refining the statistics over the population, to refine
them over various windows , in an ad hoc manner to begin, but later in a
sense maximizing the information in successive refinement of the
statistical content. Then those instance statistics would also go into
the statistic object.

Anyways back to implementing a composition hierarchy, I guess in a sense
it is about the notion of object persistence, object/relational mapping
type considerations. It seems that it would be a good idea to indicate
the composition hierarchy with regards to a sense of matching a database
implementation, of course towards abstraction away from actually
considering the implementation, in generating the code to present a
convenient object layer. It would be good to have, even for efficient
use of memory, normalization of the composed objects contents.

Basically I want to find a nice way to implement, here in C++, object
hierarchies for effectively representing data, and to have it work well
with the object-relational mapping, and have it be easily specifiable so
that for example a tool could read an XML schema and generate a
specialized C++ object hierarchy for that kind of objects with the
database mapping, or vice versa, there are probably some great tools for
that already, although I don't know them. There are also many various
modeling tools that would have this kind of notion, besides database
designers and so on. Some of those might generate rich C++ objects with
the nested iterators and so on.

I think it's funny that the decomposed type B of A, A has-a B, but
derived type B of A, B is-a A, they're reversed, in a sense, composition
and inheritance.

Merci beaucoup pour votre reponse,

Ross F.