On Sat, 15 Jun 2013 11:10:48 -0300 Felipe Magno de Almeida <[email protected]> said:
> On Sat, Jun 15, 2013 at 1:03 AM, Carsten Haitzler <[email protected]> > wrote: > > On Fri, 14 Jun 2013 13:01:23 -0300 Felipe Magno de Almeida > > <[email protected]> said: > > > >> On Fri, Jun 14, 2013 at 12:52 PM, Carsten Haitzler > >> <[email protected]>wrote: > > Hi Carsten, > > [snip] > > >> With macros I can't define local variables or structs, and with C++ I'm > >> also restricted > > > > well you can define local vars in macros.. but those method macros don't do > > that. eo uses varargs. so: > > > > eo_do(obj, efl_color_set(10, 20, 30, 40)); > > > > ACTUALLY is > > eo_do(obj, EFL_COLOR_SET, 10, 20, 30, 40); > > > > the macro just makes the stream of args look function-like thus making it > > more convenient and pretty... > > I don't think you understand what I mean. What i mean is that when you define > a macro efl_color_set, even in C I can't do this simple thing: > > void foo() > { > int efl_color_set; > } > > or even > > struct foo > { > int efl_color_set; > }; > > Which means that this macro is not at all like a function, because macros > don't obey scopes as functions do. I know, in C the scopes are quite limited > because of the lack of proper namespaces (there's only two free scopes, > the global one, and the structs one). But functions only clash with the global > scope, and macros clash with *all scopes*. So they are not the same at all > in C, and are even more nightmarish in C++. Just see the problems that > are common place from min/max and most Win32API (CreateFile et al) > from windows.h i know this. this is what i said.. welcome to c... that is why it's efl_* or evas_* or edje_*. if your app or other lib steps on this namespace.. too bad. thats WHY we bother to use a namespace prefix like evas_* efl_* etc. - regardless that it may work if you delcare inside a struct but then it will be problematic as ti just looks wrong as you expect that to be a function call from efl (or evas or edje etc.)... this is like arguing that some kitchen utensil stops you from making a cake out of broccoli. it's a cake! broccoli is not for cakes!. it's another "namespace". fine - in THEORY someone might come up with some idea to use broccoli in a cake... but let's be realistic... it isn't going to happen, and if it does... the answer is "don't do it!". :) there really is no acceptable solution here. if we make it all-caps then typing out the functions becomes even more effort (hold down shift), and you still can't then use all-caps for something either... it's a technicality, not a reality. :) we should talk about real problems or improvements. not theoretical issues like "i can't make cake with broccoli" :) > > it ALSO happens to so some magic to force typechecking > > of args too (and since its a macro.. argument count as well). > > Yes, I've read the code, and I found it quite interesting the typechecking. > The only thing I'm worried about is defining lower-case keywords,because > that's what they are since they prohibit all uses of the same identifier > in *any context*, is what I believe to be problematic. Upper-cases are > a de facto namespace for macros already in C and C++, and I hope that > E uses that or finds a way to avoid lower-case macros in another way. > Because I think it will be problematic for C code, and for C++ it will give > problems for sure because C++ uses *a lot* of code in headers because > of inline functinos and templates, which raises a lot the chance of clashing > with keywords. i seriously doubt it will ever be a problem. if you make functions, (local ones) or struct members or whatever... that starts with efl_ ... then.. don't. that's a reserved namespace prefix. yes - it makes keywords. this is reality when making libraries. it's why we choose a namespace prefix. we take ownership of that. :) > >> to member-functions, classes, free-functions, basically identifiers in any > >> context which would > >> clash with efl_color_set, efl_font_set, efl_text_set, etc. And, also all > >> other > >> function names used in eo but for classes defined by third-party code to > >> which I may > >> want to interoperate now or in the future. > > > > that's why we namespace them. this is nothing new in c. yes - it affects c+ > > +. efl is able to be used from c+ but that comes with the cost of avoiding > > the namespace - just like everyone in c would have to do. there is no way > > around this. all the enums, macros, functions and structs - same story. > > See above why enums, functions and structs are not the same as macros > at all. to a programmer they are keywords. if the same keyword means different things depending if its in a struct decl vs a local var, vs a function vs something else... then it gets confusing to read the code. it is less obvious what is intended when you read the src. this is one thing that makes c a lot more maintainable and readable that c++. it's very explicit. > [snip] > > > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [email protected] > > Regards, > -- > Felipe Magno de Almeida > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
