[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] Suggestions for more readable code
From:       Carsten Haitzler (The Rasterman) <raster () rasterman ! com>
Date:       2017-03-23 6:09:15
Message-ID: 20170323150915.b7bcf29b62ce255435ea29a4 () rasterman ! com
[Download RAW message or body]

On Fri, 17 Mar 2017 16:37:37 +0900 <conr2d@gmail.com> said:

> All EFL developers know the next rule of function name and its signature.
>     _MainClass_BaseClass_MethodName(Eo *obj, MainClassData *pd, …);
> 
> However, in some cases, the name of function will be very long and it will be
> hard to distinguish one token from others. And when I add new method, I
> should type "Eo *obj, BlahBlah *pd" repeatedly. 

technically eolian_gen can actually write this for you... our current makefiles
choose not to use eolian_gen's implementation file maintainer code... :) (-g i
option to eolian_gen)... :)

> This is an idea for cleaning up function declarations by using macro.
> https://git.enlightenment.org/core/efl.git/commit/?h=devs/conr2d/cleanup_methods
> 
> 1. Using macro to write function declaration
> Macros reveals  only method name and arguments. (+ base class prefix for
> overridden method) It will be more clear to read and understand what that
> function is.

as andy said. while this saves typing it cuts down greppability of the code.
it's no longer as easy to grep for a func from gdb in the src and fund it... so
it has a downside when debugging. :(

> 2. List up all methods in the first part of C source file
> Easy to find what methods are defined for this class. (Without opening Eo
> file) Listed private methods will prevent from adding similar private methods
> again and again.

what do you mean? like force/keep the eo method implementations at the start of
the file like?

#include <...>

typedef ...;
...
static int _global1;
static int _global2;
...

_class_method1(..,) {
}

_class_meothd2(...) {
}

_class_meothd2(...) {
}

...

_private_func1(...) {
}

_private_func2(...) {
}

...

so keep all the class methods together in a batch without mixing private funcs
in between?

> 3. Pass data variable to private method not to get data structure repeatedly
> in each private method Usually private function will be called by public or
> protected function of that class, because private methods cannot be
> accessible from outside class, so we can expect that caller of private method
> already have "pd" as its argument or local variable. Passing data variable to
> private method will prevent from repeated calling of efl_data_scope_get().

then pass in the *pd data into the private func... no need to get scope
again... :) evas does a fair bit of this... in fact in some cases ONLY passes
pd... :)

> I know there are many people who don't like macro.
> (I also don't like much in most cases. It can make hard to guess the function
> name when debugging with GDB.) This is just an idea (not best one), and the
> purpose of this mail is that I want you to think of this topic when you have
> time. 😊

i think the gdb downside here is not worth it expecially with eolian_gen -g
i ... which we don't use in efl. :( we SHOULD use it.

> + I thought that the scope of all fields in Eo class is basically private,
> but in many parts of our code, I found that child class accesses the fields
> of parent class directly by efl_data_scope_get(). Is it right way? Or, shall
> I add protected property accessor for that purpose? 

this is ok - it depends on the "contract". generally in our EXTERNALLY facing
api we do NOT expose the private data struct definitions. this allows us to
change them, remove, rename and do whatever we want to our data. our ABI and
API are not tied to it. we thus prefer accessors. BUT within efl it's ok
because we actually control all parts of the code when we expose from piece of
code A to code B it's ok - if we change A we also change B and rebuild it.

so the real issue is "3rd party" use outside of efl itself. this we have to
maintain ABI compatibility with and thus don't expose outside of efl itself...
eo itself is designed to be able to do both - either expose if you want (and
then you have to expose your struct definitions and keep them stable to whoever
you expose them to), or not expose (keep it all private and change it however
you like). :)

------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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)    raster@rasterman.com


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[prev in list] [next in list] [prev in thread] [next in thread]