On Wed, 10 Aug 2016 13:03:03 -0300 Gustavo Sverzut Barbieri
<barbi...@gmail.com> said:
> On Wed, Aug 10, 2016 at 12:07 PM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Wed, 10 Aug 2016 15:41:00 +0100 Tom Hacohen <t...@osg.samsung.com> said:
> >
> >> Hey there,
> >>
> >> Sorry it took me so long to get to this one. I've been dealing with
> >> other things, and every time I got back to this I had more clashes and
> >> hell. I'm finally at a stage I can merge most of it, so I'm happy,
> >> though I have one question before I push.
> >>
> >> At the moment I changed it as follows:
> >> Eo.Base -> Efl.Object
> >> Eo.Override -> Efl.Object.Override
> >>
> >> I'm quite OK with this change. The problem comes with the actual
> >> functions. At the moment they are:
> >>
> >> efl_ref()
> >> efl_add()
> >> efl_del()
> >> efl_finalize()
> >> efl_name_set()
> >> efl_parent_get()
> >
> > these. we know at this level of the base api namespace that efl_ here is
> > actually an efl OBJECT and we are doing something to it. that's
> > understood/implied. adding more wordiness doesnt help with any of that, just
> > makes code more verbose and adds more typing effort.
>
> isn't clear to me... at least not after coming back :-)
then all those OO developers are horrible. i mean:
window.name_set("hello");
how do i know name_set() method is operating on an object? gee. it had better
become
window.object_name_set("hello");
or
window->object_name_set("hello");
ok. now i know how it works!
i'm being a bit snide :) but EFL/EO api *IS* AN OBJECT API. it's the BASIC
REQUIREMENT. they all take an object as parameter. adding object in the api
name is just repeating the information already there. it's like saying we
should name out functions in c
y = function_malloc(c);
because how could anyone know this is a function call? it's so confusing...
it's the basic tenet of the system that it IS a function just like the our efl
api it's a basic tenet of the functions that it is a method on an object. the
object is passed as first param. efl_ is the namespace to know that it is this
kind of function. eina_ is a separate namespace thats lower level like malloc()
is lower level.
you are used to the efl legacy api's where many exist that don't operate on
objects. that is not the case with eo. even class functions operate on an
object (the class is the object.. classes ARE Eo objects!).
adding "object" adds NO information, just makes lines longer, more wrapping of
long lines, more typing, more reading, no extra value.
ESPECIALLY with common things like del, add, ref, unref why type MORE than
needed? it's just a good way to annoy developers after a while. these
essentially are keywords in a language like delete() or "for" or "if" etc. - efl
is a library but essentially as a FRAMEWORK it kind of defines a language
within its namespace (efl_*) and reality is if we COULD we'd not have the
initial namespace of efl_ref(obj) but make it ref(obj). but we can't we need at
least a namespace to avoid symbol clashes and that's a hard reality of the base
language.
> if efl is all about the high-level end user API (ie: all that the user
> needs to know), then it may work if all is an object. Otherwise people
> may incorrectly assume efl_ref() could be used on an Eina_Binbuf or
> Eina_Stringshare and that won't be the case, even if they are also
> part of EFL.
it's a different namespace. it's eina_* vs efl_* already... AND the compiler
will tell you because you CANT do this without the compiler giving you a type
mismatch warning (in c and in c++). in dynamic langs this is taken care of at
runtime too. in fact we have pretty much reduced to 2 namespace. eina_ and efl_
- efl_ is the object namespace as you describe above. eina_ is lower level data
structures. i actually think we should consider renaming eina to maybe et_ or
something shorter and different for efl 2.0 just to one api and abi break away
(thats an easy sed operation to fix) and that then allows us to do any little
fixups. i think our lists should work more like arrays/hashes, and copying the
glib list style i think is a bit bad. anyway - long story short.. it would
still be a different namespace and not full efl objects for these.
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (16) 99354-9890
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
