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

fir wrote:

[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

there is also a matter of type
becouse say you got such things
s.x()
s.y()
t.x()
t.y()
u.x()
u.y()
w.x()
w.y()
there is no need to define 'type' at all?
or meybe its a need and say soem may define
one type say "chase" where s, and t belong and
second type where say "cake" u and w belong
i must say im closer to thought maybe not to define such
types but im not strictly sure they could not be handy
and needed in some cases
if no that would mean it all belongs to the same type
but names x,y are very meaningfull.. and whay is named x
means the same as to 'type' in various structures
there is also a question what to do in such cases
s.a
s.x()
s.y()
t.x()
t.y()
t.z()
u.b
u.x()
u.y()
w.a
w.x()
w.y()
w.z()
does the 'subtypes' (or suptypes, what i write
by typo here) need to be automatically 'generated'/reckognized
possibly maybe those 'suptypes' are those interfaces
- and those interfaces need to defined in usage point
say function f needs
void f("x()", "y()", "z()")
(where this in quites is a stub as im not sure how to write this)
then possibly this usage generates intefrace - though
possibly those interfaces could be generated separatelly
tag animal
{
   x();
   y();
   z();
}
there is here a lot of a bit blind thinking on my side
(i mean such thinking im not sure, seen things in kinda
emptinnes) but thise remarks seem to have soem sense to me