On 11/08/16 03:34, Carsten Haitzler (The Rasterman) wrote:
> 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.
>
I tend to agree with you (that's why I originally did the change like
this). Should I go on with this then? Any major objections to this rebuttal?
--
Tom.
------------------------------------------------------------------------------
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
