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

fir wrote:

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
>

maybe some relation among the types would come naturally like
if
interface animal
{
   void a();
   void b();
   void c();
   void d();
   void e();
   void f();
}
is animal then things liek that
interface zzz
{
   void a();
   void b();
   void c();
   void e();
   void f();
}
interface bbb
{
   void a();
   void b();
   void c();
   void d();
   void e();
}
would be maybe subanimals (almost animals)
and things liek that
interface dddd
{
   void a();
   void b();
   void c();
   void d();
   void e();
   void f();
   void g();
}
interface dddd
{
   void a();
   void b();
   void c();
   void d();
   void e();
   void f();
   void z();
}
super animals (over animals)
and it shows given type has many subtuypes and many supertypes so
tree structure (which i know is not sufficient) is broken