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)