theorethical thought on tree structure, fields, tags and so called tag system (oryginal)

[i added teh tag oryginal - as in fact most of what i write aroound c
language theory are oryginal thoughts, not something that i just read or seen somewhere - to be clear)
i thought a bot on things like that
some {
   void a() {}
   void b() {}
}
some2 {
   void a() {}
   void b() {}
}
and soem obserwation is its probably more convenient to
write
   void some.a() {}
   void some.b() {}
   void some2.a() {}
   void some2.b() {}
wchich my be seen as critique of this module {} convention
(where opening s far to closing
then you can call foo(some) or foo(some2) for some advantage
but if so this convention will probably build a tree
structure over the fields and i once noticed tree
structure is not best for some things (liek in need
for soem things people calls polymorphism)
it seems something i call 'tags' is better - it is
situation ehen given thing has more than one parent
but im not sure how to 'bite' this
say soem example
     car.wheels
     car.doors
     car.engine
     car.move()
     boat.engine
     boat.turbine
     boat.move()
car is vehicle, and say when car in programming
world is full structure the vehicle is probably more
the interface that car should give as its vehicle
so "vehicle" is something other than auperfield
(or how to call it) it must be something other,
maybe i should call it tags
im not in mood to write on it more today (not much good
form and focus) but from this whai i write imo
teh conclusion is probably - treelike structures and fields
are not enough to do what is called polymorphism
(and soem interface related things) so there is a need
of define soem "tag system" probably aside of that