From Newsgroup: comp.lang.c

i once remember was writing about things that inheritance is wrong
-
the general conclusion realated to this (though specific conclusuins was
other i dont remember but it was thatmore proper inheritance is
(i donr remember) containing of substrutures (i dont remember so
this is in arhive of this group, i remember i was writing on this)

the general conclusion related to his is could ba said that tag systems
are much better than tree structures - thsi is becouse if you have
something (say its file) you could only have one directory and one
directory above this when in reality you would like to have many
- its tag system (or what its called if it have other name, i call it
tag system)

i not noticed hovever stict conclusion fo it : C scopes

c scopes have tree structure { {}{{}{}}} etc so they ate just wrong

you should allow the intersection od scopes

like
a{

b{
}//end of a


} //end of b

to simoply making as shaped scopes as you need, definitelly there is
probably a need of naming them so it probably mean you need to tag
things in c

tag
{
a() {}
b() {}
d() {}
}

or

tag a() {}
tag b() {}
tag2 d() {}

a bit shocking conclusion as it kinda obvious but never noticed


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 12 May 2026 12:22:20 +0200, fir wrote:

c scopes have tree structure { {}{{}{}}} etc so they ate just wrong

Just too limited. Lexical binding is better. You see the difference in languages which allow nested function/class definitions.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Lawrence DrCOOliveiro pisze:

On Tue, 12 May 2026 12:22:20 +0200, fir wrote:

c scopes have tree structure { {}{{}{}}} etc so they ate just wrong

Just too limited. Lexical binding is better. You see the difference in languages which allow nested function/class definitions.

what do you mean? you could give example if you want
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Wed, 13 May 2026 10:42:08 +0200, fir wrote:

Lawrence DrCOOliveiro pisze:

On Tue, 12 May 2026 12:22:20 +0200, fir wrote:

c scopes have tree structure { {}{{}{}}} etc so they ate just
wrong

Just too limited. Lexical binding is better. You see the difference
in languages which allow nested function/class definitions.

what do you mean? you could give example if you want

In <https://gitlab.com/ldo/pysmb2>, the function rCLdef_struct_classrCY is
a class factory -- it creates a new class every time it is called.
This is used to define the following classes, each of which is a
high-level wrapper around a corresponding C object in libsmb2:

Dirent = def_struct_class \
(
name = "Dirent",
ctname = "dirent",
specialmap =
{
"name" : lambda n : n.decode(),
}
)
FileBasicInfo = def_struct_class \
(
name = "FileBasicInfo",
ctname = "file_basic_info",
specialmap =
{
"creation_time" : lambda t : t.timeval,
"last_access_time" : lambda t : t.timeval,
"last_write_time" : lambda t : t.timeval,
"change_time" : lambda t : t.timeval,
}
)
FileStandardInfo = def_struct_class \
(
name = "FileStandardInfo",
ctname = "file_standard_info"
)
FileAllInfo = def_struct_class \
(
name = "FileAllInfo",
ctname = "file_all_info",
specialmap =
{
"basic" : lambda i : FileBasicInfo.from_ct(i),
"standard" : lambda i : FileStandardInfo.from_ct(i),
# "name_information"?
}
)
FileFSSizeInfo = def_struct_class \
(
name = "FileFSSizeInfo",
ctname = "file_fs_size_info"
)
FileFSDeviceInfo = def_struct_class \
(
name = "FileFSDeviceInfo",
ctname = "file_fs_device_info"
)
FileFSControlInfo = def_struct_class \
(
name = "FileFSControlInfo",
ctname = "file_fs_control_info"
)
FileFSFullSizeInfo = def_struct_class \
(
name = "FileFSFullSizeInfo",
ctname = "file_fs_full_size_info"
)

Lexical binding is key to that working.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Lawrence DrCOOliveiro pisze:

On Wed, 13 May 2026 10:42:08 +0200, fir wrote:

Lawrence DrCOOliveiro pisze:

On Tue, 12 May 2026 12:22:20 +0200, fir wrote:

c scopes have tree structure { {}{{}{}}} etc so they ate just
wrong

Just too limited. Lexical binding is better. You see the difference
in languages which allow nested function/class definitions.

what do you mean? you could give example if you want

In <https://gitlab.com/ldo/pysmb2>, the function rCLdef_struct_classrCY is
a class factory -- it creates a new class every time it is called.
This is used to define the following classes, each of which is a
high-level wrapper around a corresponding C object in libsmb2:

Dirent = def_struct_class \
(
name = "Dirent",
ctname = "dirent",
specialmap =
{
"name" : lambda n : n.decode(),
}
)
FileBasicInfo = def_struct_class \
(
name = "FileBasicInfo",
ctname = "file_basic_info",
specialmap =
{
"creation_time" : lambda t : t.timeval,
"last_access_time" : lambda t : t.timeval,
"last_write_time" : lambda t : t.timeval,
"change_time" : lambda t : t.timeval,
}
)
FileStandardInfo = def_struct_class \
(
name = "FileStandardInfo",
ctname = "file_standard_info"
)
FileAllInfo = def_struct_class \
(
name = "FileAllInfo",
ctname = "file_all_info",
specialmap =
{
"basic" : lambda i : FileBasicInfo.from_ct(i),
"standard" : lambda i : FileStandardInfo.from_ct(i),
# "name_information"?
}
)
FileFSSizeInfo = def_struct_class \
(
name = "FileFSSizeInfo",
ctname = "file_fs_size_info"
)
FileFSDeviceInfo = def_struct_class \
(
name = "FileFSDeviceInfo",
ctname = "file_fs_device_info"
)
FileFSControlInfo = def_struct_class \
(
name = "FileFSControlInfo",
ctname = "file_fs_control_info"
)
FileFSFullSizeInfo = def_struct_class \
(
name = "FileFSFullSizeInfo",
ctname = "file_fs_full_size_info"
)

Lexical binding is key to that working.

uh i dont know c++ and i got a problem learning it..

but it seems "lexical binding" is what you got in c and this is not
enough - as i previously wrote i think in language you should hae much
more freedom to shape scopes on your own

the solution is something like tag system probbaly i mean you could define

system
{

renderer { //one scope

init();
blit();
resize();
//...
raster_functions
{
draw_line();
fill_circle();
}

audio //audio scope
{
play_wav();


}
io
{
load();
audio
{
load_wav();
}
}

here scopes are nested and load_wav() belong to both io scopa and audio
scope

the cases of using it are yet to bee seen..but i think it is needed


}

}
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

system
{

renderer { //one scope

-a-a-a init();
-a-a-a blit();
-a-a-a resize();
-a-a-a //...
raster_functions
{
-a-a draw_line();
-a-a fill_circle();
}

-aaudio //audio scope
-a {
-a-a-a-a play_wav();

-a }
-aio
-a{
-a-a-a-a load();
-a-a-a-a audio
-a-a-a-a {
-a-a-a-a-a-a load_wav();
-a-a-a-a-a }
-a}

sorry mistyoes in braces

system
{

renderer { //one scope

init();
blit();
resize();

raster_functions
{
draw_line();
fill_circle();
}
} //end of renderer scope

audio //audio scope (in system scope)

{
play_wav();


}

io //in system scope
{
load();

audio //additional part of audio scope in io scope
{
load_wav();
}
}
}

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

system
{

renderer { //one scope

-a-a-a-a init();
-a-a-a-a blit();
-a-a-a-a resize();
-a-a-a-a //...
raster_functions
{
-a-a-a draw_line();
-a-a-a fill_circle();
}

-a-aaudio //audio scope
-a-a {
-a-a-a-a-a play_wav();


-a-a }
-a-aio
-a-a{
-a-a-a-a-a load();
-a-a-a-a-a audio
-a-a-a-a-a {
-a-a-a-a-a-a-a load_wav();
-a-a-a-a-a-a }
-a-a}

sorry mistyoes in braces

system
{

renderer { //one scope

-a-a-a init();
-a-a-a blit();
-a-a-a resize();

raster_functions
{
-a-a draw_line();
-a-a fill_circle();
}
} //end of renderer scope

-aaudio //audio scope (in system scope)

-a {
-a-a-a-a play_wav();

-a }

-aio //in system scope
-a{
-a-a-a-a load();

-a-a-a-a audio //additional part of audio scope in io scope
-a-a-a-a {
-a-a-a-a-a-a load_wav();
-a-a-a-a-a }
-a}
}

this is close to namespaces but i thing it should be scopes and more use
it could be done..dont know maybe it two distant functions have static variables they could see each other ones

scopes are also more rigid than namespaces it is if youre not in scope
you cant use something at all

they are also kinda different than modules as two modules cant normally
share one functions that it belong to both of them and has scope of both

such system could possibly maybe provide more strict scoping thuis
increasing so called 'safety' in some way (liek some newb programmeh has
to have harder to spoil something and also make bad design)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Wed, 13 May 2026 11:57:06 +0200, fir wrote:

but it seems "lexical binding" is what you got in c and this is not
enough ...

No, you havenrCOt got lexical binding in C, or I think C++, because they donrCOt need it. They donrCOt permit one function to be defined anywhere
inside another.

Java does have it, in a limited form -- the referenced names must be
declared rCLfinalrCY. Maybe this is to avoid inadvertent modifications;
Python solves that problem in a slightly different way.
--- Synchronet 3.22a-Linux NewsLink 1.2