2016-08-10 17:07 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>:
> 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.
>
>
This shorts names seems totally wrong to me, what you are assuming ("at
this
level of the base api...") is an implicit assumption that can only confuse
users.
Explicit is better than Implicit is in general my rules of life.
Take the efl_finalize() for example, it should really shutdown the whole
library.
So my vote goes for the longer ones.
> > Are we fine with these names, or should they be:
> >
> > efl_object_ref()
> > ...
> > efl_object_parent_get()
> >
> > What do you prefer?
> >
> > I'm quite OK with the former, but would rather not rewrite the whole of
> > EFL twice. :)
> >
> > Please let me know, I'd like to push it in the next 24hrs to avoid
> > further clashes.
> >
> > Thanks,
> > 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
> >
>
>
> --
> ------------- 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
>
------------------------------------------------------------------------------
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
