Re: enum sets

fir wrote:

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
>

how it differs form c++ crap?  i dont much remember c++ crap but the
difference here is slight but notable
i remember vagulelly if you have structure then you have
substructures inside which you can cast don (i dont remember
it needed to be naed, or if you can cast only to first
byte or if you get 3 substructores you can cast on each
S { A, B, C}
foo( (A) S) //downcast S to A
foo( (B) S) //downcast S to B
for sure you couldnt obtain the full combination
and if you get structure that has 3 filelds (a,b,c) you got
poteintially a lot of subtypes
a
b
c
a b
a c
b c
a b c
here you simply can cast on any subtype (and subtype is any
combination of fields (order not important i mean "a c" is same as "c a" as "a c" constitutes interface))
so what they name "subclass" is not what they name but any interface
that you need build form any fields - it would be "subclass" for them
(not what they call subclass which is defined with that silly
class A : B or something