Thiago Adams <[email protected]> writes:
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
If I understand you correctly, enum monospaced_font_type is a *subtype*
of enum font_type.
Ada has something very similar to this:
type Font_Type is (CASCADIA_FONT, ARIAL_FONT);
subtype monospaced_font_type is Font_type range CASCADIA_FONT .. CASCADIA_FONT;
An Ada subtype is a type with an optionally added *constraint*,
which can be checked at runtime. But it's hard to see how you'd
add this to C.
Given your type definition, how would this behave?
void func(enum monospaced_font_type);
enum font_type font = ARIAL_FONT;
func(font);
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
- i was also inspired by
concept of interface - is used in some languages (and such form of
this interface it looks like structure of data and function calls)
hovever worth noticing if you add some method to
this 4op number (like .jump() or .beep()) then this
4op number geting be super over ints and floats in that area
being "sub" in area of binary representation
Thiago Adams wrote:
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
this is about general problem of what i name polymorphism
but maybe its not right name, it is about variety of types
and subtypes
let think abit about that
in c you got more like types not deal with subtypes
and supertypes like you got type int and type float
but they both number.. not knowing at this moment
if that "number" is subtype or supertype
dafine numeber is something you can +-&/ i mean
define some interface and what conforms is a number
(im not sure if its right but assume) then both int and
float seem to be equal types (?) i mean type is
in fact "number" and ints and floats are specific
representations.. both are somewhat 'super' above this
simpel 4operators number coz they have this exact binary
representation and interpretation low lewel people
know ..hovever worth noticing if you add some method to
this 4op number (like .jump() or .beep()) then this
4op number geting be super over ints and floats in that area
being "sub" in area of binary representation
so it clearly shows that this superiority and sub-ness
(or how to call it) may be (and is) partial and inter-mixed
this all shows how this c++ polymorphism is bulshit
(which i know from first time seing it around 25 years ago)
(those sektor van skiljen tutorial times - good times)
in c as i wrote few days ago probably the interfaces
can cover those things and interfaces are kinda
natural - as function header is natuiral interface
though this would need to be organized somewhat i guess
as this interface potential is not much used now (it seems)
as to enums i dont know..but worth noticing this
supertype things not goes left-side but right-side
in structure definition i mean
point
{
int x;
int y;
}
the superiority you dont do adding things on left
chase
{
point
{
int x;
int y;
}
}
but
point
{
int x;
int y;
int chase_thing;
}
and thsi seems to be their flaw
(Its probably becouse on the left you got tree structure
avaliable - and on the right you got full combinations
avaliable
(i not rethinked it fully but noticed that things
with time and recently wrote on it in a thread on
"tree structures and polymorphism")
(and what i say is also about enums i guess, i mean
one should not define characteristic of such enums on the
left but "in" the right
is_tree
{ some_enum }
some_enum
{
is_tree;
is_short;
}
(note what i say is my oryginal work
i tell it becouse i know some people can take it not credit me,
than repeat to some other folks, who then will say "eureka"
i found much interesting thing, which comes to my mind
when soem x was saying on this (and this x took if from me)
(so just to be honest for truth)
(and by what i was inspired - i was inspired by word and idea of "tag"
(like those tags used in net)
- i just noticed that many groups of varius things you can tag
and you may organise those tags, but those tags croses over (out) the
tree
structure so tree structure for such things - i was also inspired by
concept of interface - is used in some languages (and such form of
this interface it looks like structure of data and function calls)
fir wrote:
Thiago Adams wrote:
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
this is about general problem of what i name polymorphism
but maybe its not right name, it is about variety of types
and subtypes
let think abit about that
in c you got more like types not deal with subtypes
and supertypes like you got type int and type float
but they both number.. not knowing at this moment
if that "number" is subtype or supertype
dafine numeber is something you can +-&/ i mean
define some interface and what conforms is a number
(im not sure if its right but assume) then both int and
float seem to be equal types (?) i mean type is
in fact "number" and ints and floats are specific
representations.. both are somewhat 'super' above this
simpel 4operators number coz they have this exact binary
representation and interpretation low lewel people
know ..hovever worth noticing if you add some method to
this 4op number (like .jump() or .beep()) then this
4op number geting be super over ints and floats in that area
being "sub" in area of binary representation
so it clearly shows that this superiority and sub-ness
(or how to call it) may be (and is) partial and inter-mixed
this all shows how this c++ polymorphism is bulshit
(which i know from first time seing it around 25 years ago)
(those sektor van skiljen tutorial times - good times)
in c as i wrote few days ago probably the interfaces
can cover those things and interfaces are kinda
natural - as function header is natuiral interface
though this would need to be organized somewhat i guess
as this interface potential is not much used now (it seems)
as to enums i dont know..but worth noticing this
supertype things not goes left-side but right-side
in structure definition i mean
point
{
int x;
int y;
}
the superiority you dont do adding things on left
chase
{
point
{
int x;
int y;
}
}
but
point
{
int x;
int y;
int chase_thing;
}
and thsi seems to be their flaw
(Its probably becouse on the left you got tree structure
avaliable - and on the right you got full combinations
avaliable
(i not rethinked it fully but noticed that things
with time and recently wrote on it in a thread on
"tree structures and polymorphism")
(and what i say is also about enums i guess, i mean
one should not define characteristic of such enums on the
left but "in" the right
is_tree
{ some_enum }
some_enum
{
is_tree;
is_short;
}
(note what i say is my oryginal work
i tell it becouse i know some people can take it not credit me,
than repeat to some other folks, who then will say "eureka"
i found much interesting thing, which comes to my mind
when soem x was saying on this (and this x took if from me)
(so just to be honest for truth)
(and by what i was inspired - i was inspired by word and idea of "tag"
(like those tags used in net)
- i just noticed that many groups of varius things you can tag
and you may organise those tags, but those tags croses over (out) the
tree
structure so tree structure for such things - i was also inspired by
concept of interface - is used in some languages (and such form of
this interface it looks like structure of data and function calls)
there is also ofc a fact of how this right (proper)
polymorphism would be usable as i dont know
i may maybe imagine some usecase :
say you got entities/elements (structures) sprites
each has something like x,y where its placed, on/off
state , soem may have orientation (rotation angle),
soem may be clickable and some of clicabel be type
(supertype) widgets, soem of them could be maybe soem
more advanced supertype of widgets like agents (?)
i dont know possibly this just helps a bit in composition
- depending how its done
some things can be done easy i guess
say
sprite //say simpel sprite
{
rectangle area; // like centre, and w,h
char* bacground_bitmap_name ;
int HP;
int amunition;
}
widget
{
rectangle area;
char* bacground_bitmap_name;
on_click(int x, int y) { beep();}
}
void draw_bitmap({rectangle area, char* bacground_bitmap_name}*)
{
//...
}
void register_widget({rectangle area, on_click*(int , int)}*)
{
}
foo()
{
sprite s = { {100,100,20,20}, "some.bmp", 100,20};
widget w = { {200,100,20,20}, "some.bmp" };
draw_bitmap(s); //can draw anything that has "rectangle area" and "char* bacground_bitmap_name" - binding is compile time by names
draw_bitmap(w);
register_widget(w); //can register anything that has rectangle
area and on_click method
}
this example shows that there are functions that accepts given
structure fields and soem may pas "wider" structures into them and
they will cast down
to what they need (compiler will jus pass pointer or pointers )
the open question is if to define and name thos interfaces
like
draw_bitmap_interface
{
rectangle area,
char* bacground_bitmap_name }
and then
void draw_bitmap(draw_bitmap_interface*) {}
or meke it ad-hoc (probably both)
how much usefull? probably usefull but not much revolution it seems
(but probablu usefull)
and question is if to bind by type or by name, both coul;d be done
but if by type some typedefs need to be inwolved like
typedef {char*} bitmap_name;
sprite
{
rectangle area;
bitmap_name name;
}
maybe messy example but closes to how it can be done
On 29/08/2024 05:18, fir wrote:
Thiago Adams wrote:
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
this is about general problem of what i name polymorphism
I was considering the name polymorphic enum. But polymorphism is more
about hierarchies.
For this feature it can be any set you want. We can have duplicates.
enum E
{
enum set1 {
A
},
enum set2 {
A,
B
}
}
as to enums i dislike them a lot.. realy sometimes is better tu use
'asd' and sometimes even strings and comepare by strcomp
I am wondering how useful would be to have enum sets.
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
may be probably bad becouse you want to have 2 keys so
it should be more like
enum A:shbshb
enum B:shbshbskjs
enum B:shbshbjskj
enum A:B:shbshbskjs
Thiago Adams wrote:
I am wondering how useful would be to have enum sets.reading yet once i dont know what you want
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
i guess you maybe say what i understand as kinda "micro dictionary"
i mean say 32 bits of enum offes space to give some section for
"keys" and some section for "values" (for example upper 8 bits
for keys 1-255 enumized or not - and 24 bits for values - also enumized
or not...such microdictionary is good idea..i guess people
sometimes use it but in fact enum statement dont support it afair
though as i said the form of defining it
enum
{
AJHJH
{
KJHZ,
HJKJHG,
HJHJH,
}
AJJHKJH
{
KJHZ,
HJKJHG,
HJHJH,
}
}
may be probably bad becouse you want to have 2 keys so
it should be more like
enum A:shbshb
enum B:shbshbskjs
enum B:shbshbjskj
enum A:B:shbshbskjs
On 29/08/2024 10:09, fir wrote:
Thiago Adams wrote:
I am wondering how useful would be to have enum sets.reading yet once i dont know what you want
Let´s say you have a function that accepts only monospaced fonts.Then
you can use enum monospaced_font_type. Or a switch case where you need
to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
i guess you maybe say what i understand as kinda "micro dictionary"
It does not use bits. Each enumerator will have a sequential number like
it is today.
When the same enumerator is used twice the number does not change.
Sample:
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT,
enum modern_monospaced_font_type
{
CASCADIA_FONT,
},
};
CASCADIA_FONT is 0
ARIAL_FONT is 1
The implementation could work like this:
Each enum has a set of "parent enums."
A cast or conversion from one enum to another will trigger a warning if
the target type is not in the parent set.
For instance, casting from enum monospaced_font_type to enum font_type
is fine because the parent set of enum monospaced_font_type is { enum font_type }.
Each enumerator will also have its own parent set, representing the
enums it belongs to. For example, CASCADIA_FONT belongs to { enum monospaced_font_type, enum font_type } .
Therefore, converting an enumerator to any enum in its parent set is acceptable; otherwise, a warning will be issued.
In a switch case for an enum type, we must ensure that all enumerators
of that type are present.
For example, in a switch statement for enum font_type, we need to check
that all enumerators with enum font_type in their parent set are included.
Unfortunately, C does not have good
support or syntax for sum types - it all has to be handled manually and
with either extra wrapping or no type safety.
Thiago Adams wrote:
On 29/08/2024 10:09, fir wrote:ok i guess i undestand what you talkin about
Thiago Adams wrote:
I am wondering how useful would be to have enum sets.reading yet once i dont know what you want
Let´s say you have a function that accepts only monospaced fonts.Then >>>> you can use enum monospaced_font_type. Or a switch case where you need >>>> to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or
font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
i guess you maybe say what i understand as kinda "micro dictionary"
It does not use bits. Each enumerator will have a sequential number like
it is today.
When the same enumerator is used twice the number does not change.
Sample:
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT,
enum modern_monospaced_font_type
{
CASCADIA_FONT,
},
};
CASCADIA_FONT is 0
ARIAL_FONT is 1
The implementation could work like this:
Each enum has a set of "parent enums."
A cast or conversion from one enum to another will trigger a warning if
the target type is not in the parent set.
For instance, casting from enum monospaced_font_type to enum font_type
is fine because the parent set of enum monospaced_font_type is { enum
font_type }.
Each enumerator will also have its own parent set, representing the
enums it belongs to. For example, CASCADIA_FONT belongs to { enum
monospaced_font_type, enum font_type } .
Therefore, converting an enumerator to any enum in its parent set is
acceptable; otherwise, a warning will be issued.
In a switch case for an enum type, we must ensure that all enumerators
of that type are present.
For example, in a switch statement for enum font_type, we need to check
that all enumerators with enum font_type in their parent set are
included.
you want a list of enums say from 0 to 1703 ordinally on binary level
but but you also want to compiler build a table to which group it belong
but not encode it as bits
if so if you want to repeat given emon in more groups than you need to
not give it new walue instead given enum would have two walues
it can be done and gives something like more typesafety but the microdictionary is imo much more interesting idea - as those dictionary things are in a way fundamental in programming
fir wrote:
Thiago Adams wrote:
On 29/08/2024 10:09, fir wrote:ok i guess i undestand what you talkin about
Thiago Adams wrote:
I am wondering how useful would be to have enum sets.reading yet once i dont know what you want
Let´s say you have a function that accepts only monospaced fonts.Then >>>>> you can use enum monospaced_font_type. Or a switch case where you need >>>>> to check all and only monospaced_font_type.
But at same type you can store at same object monospaced_font_type or >>>>> font_type.
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT
};
This could be arranged in any way.
i guess you maybe say what i understand as kinda "micro dictionary"
It does not use bits. Each enumerator will have a sequential number like >>> it is today.
When the same enumerator is used twice the number does not change.
Sample:
enum font_type
{
enum monospaced_font_type
{
CASCADIA_FONT,
},
ARIAL_FONT,
enum modern_monospaced_font_type
{
CASCADIA_FONT,
},
};
CASCADIA_FONT is 0
ARIAL_FONT is 1
The implementation could work like this:
Each enum has a set of "parent enums."
A cast or conversion from one enum to another will trigger a warning if
the target type is not in the parent set.
For instance, casting from enum monospaced_font_type to enum font_type
is fine because the parent set of enum monospaced_font_type is { enum
font_type }.
Each enumerator will also have its own parent set, representing the
enums it belongs to. For example, CASCADIA_FONT belongs to { enum
monospaced_font_type, enum font_type } .
Therefore, converting an enumerator to any enum in its parent set is
acceptable; otherwise, a warning will be issued.
In a switch case for an enum type, we must ensure that all enumerators
of that type are present.
For example, in a switch statement for enum font_type, we need to check
that all enumerators with enum font_type in their parent set are
included.
you want a list of enums say from 0 to 1703 ordinally on binary level
but but you also want to compiler build a table to which group it belong
but not encode it as bits
if so if you want to repeat given emon in more groups than you need to
not give it new walue instead given enum would have two walues
it can be done and gives something like more typesafety but the
microdictionary is imo much more interesting idea - as those dictionary
things are in a way fundamental in programming
overaly i would said this is good idea - but its generalisation: much
better (could said weird i never thought concretely on this
microdictionaries though i dropped thinking on C for months completely)
how to define such microdictionary i dont know
it could be (speaking on old c style) something like
dictionary int some[int];
some[110]=10;
some['kot']='dog';
some[enum lalla]=enum bababa;
such int-int implementation would need 64 bit value
those entries abowe would be 3 64 bit numbers
more entries for one key, no problem
some['kot']='mors';
just another number added
(so possibly two types of dictionaries can be defined if not more
also i gues bitfields can be used
dictionary signed:10 some[signed:22];
also such syntax probably is acceptable
dictionary void some[signed:22][signed:10];
some[29][233];
now this is container that stores void
David Brown wrote:
Unfortunately, C does not have good
support or syntax for sum types - it all has to be handled manually and
with either extra wrapping or no type safety.
<https://github.com/Hirrolot/datatype99>
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 150:13:05 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,595 |