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

[fir]

[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

[fir]

Post by fir
[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

[fir]

Post by fir

Post by fir
[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