On Sat, Jun 15, 2013 at 3:01 PM, Carsten Haitzler <ras...@rasterman.com>wrote:
> On Sat, 15 Jun 2013 11:10:48 -0300 Felipe Magno de Almeida
> <felipe.m.alme...@gmail.com> said:
>
> > On Sat, Jun 15, 2013 at 1:03 AM, Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> > > On Fri, 14 Jun 2013 13:01:23 -0300 Felipe Magno de Almeida
> > > <felipe.m.alme...@gmail.com> said:
> > >
> > >> On Fri, Jun 14, 2013 at 12:52 PM, Carsten Haitzler
> > >> <ras...@rasterman.com>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) ras...@rasterman.com
> >
> > Regards,
> > --
> > Felipe Magno de Almeida
> >
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
https://www.etsy.com/storque/media/articles/2010/09/10354-GC_Top_lg.jpg
Just to illustrate the discussion, yep .. broccoli cakes looks like
failure.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
