Re: [E-devel] Eo: static methods or C syntax sugar for class methods?

2016-12-21 Thread Gustavo Sverzut Barbieri 
>> but if we do a macro that counts the number of parameters and if no
>> class is given it would assume the default class (base), that's easier
>> to use.
>>
>
> I'm a bit worried about the naming scheme for those macros, as they would
> then have to merge a full method name (eg. my_first_class_func) and the
> implementing class name (eg. my_other_class). I honestly didn't really
> think of this idea as very neat because of this ;) But maybe you have a
> good idea?

well, I'd suggest to skip the first name, just the second:

my_other_class_func()

Example:

a_create()
b_create()

but maybe we'll have to live with C nasty bits... after all look at this:

   dialer = efl_add(EFL_NET_DIALER_HTTP_CLASS, loop,
efl_name_set(efl_added, "dialer"),
efl_net_dialer_http_method_set(efl_added, method),
efl_net_dialer_http_primary_mode_set(efl_added,
primary_mode),
efl_net_dialer_http_version_set(efl_added, http_version),
efl_net_dialer_http_authentication_set(efl_added,
username, password, authentication_method, authentication_restricted),
efl_net_dialer_http_allow_redirects_set(efl_added,
allow_redirects),
efl_net_dialer_http_cookie_jar_set(efl_added, cookie_jar),
efl_net_dialer_proxy_set(efl_added, proxy),
efl_net_dialer_timeout_dial_set(efl_added, timeout_dial),
efl_event_callback_array_add(efl_added,
dialer_cbs(), NULL));

Where not only you have to replicate the namespace multiple times, you
also have to resolve the method yourself (note:
efl_net_dialer_proxy_set() is in the base class, while others are in
the specific class. Not to say the replication of "efl_added, "

At first I found that Gobject's name-as-string was bad, but looking at
this it does help usability at the expense of string lookups and lack
of compile-time errors due typos and incorrect types:

   dialer = g_object_new(cls, "method", method, "proxy", proxy...);

which is closer to high level bindings, I'd expect in Python it to be:

   dialer = Efl.Net.Dialer.Http(method=method, proxy=proxy...)



> As you may know I've used such a factory for input events, and the syntax
> is a bit crappy (but it returns the private data, which is convenient for
> internal code).

That private data thing did annoy me, but I didn't look into much
detail how we could fix that.

In Ef.Net I use some @protected methods only meant at subclasses to
override behavior... maybe that could work there?

-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: static methods or C syntax sugar for class methods?

2016-12-20 Thread Jean-Philippe André 
Hey k-s,

On 20 December 2016 at 20:03, Gustavo Sverzut Barbieri 
wrote:

> On Mon, Dec 19, 2016 at 11:05 PM, Jean-Philippe André 
> wrote:
> > On 19 December 2016 at 21:10, Gustavo Sverzut Barbieri <
> barbi...@gmail.com>
> > While these are nice to be "class methods" since one could get these
> >> to work with subclasses, they are often used with the original class.
> >> Then my request is to either to introduce a "staticmethod" OR to use
> >> some macro trick to count the number of parameters and pass the class
> >> automatically when omitted or generate 2 functions, one with class and
> >> another without (one could be an actual function, while the other just
> >> a macro).
> >>
> >> End goal is to make these look more like:
> >>
> >> efl_net_ip_address_create(1234, "127.0.0.1");
> >
> >
> > A macro could be nice. We still need @class functions to work with other
> > classes than the one that declares the method. Each class can then have
> its
> > own implementation of the common @class function. Should all sub
> > implementations also provide a macro, then?
>
> that's a neat idea, to generate the macros with the new name if
> "implements"
>
> but if we do a macro that counts the number of parameters and if no
> class is given it would assume the default class (base), that's easier
> to use.
>

I'm a bit worried about the naming scheme for those macros, as they would
then have to merge a full method name (eg. my_first_class_func) and the
implementing class name (eg. my_other_class). I honestly didn't really
think of this idea as very neat because of this ;) But maybe you have a
good idea?

As you may know I've used such a factory for input events, and the syntax
is a bit crappy (but it returns the private data, which is convenient for
internal code).

-- 
Jean-Philippe André
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: static methods or C syntax sugar for class methods?

2016-12-20 Thread Tom Hacohen 
On 20/12/16 11:03, Gustavo Sverzut Barbieri wrote:
> On Mon, Dec 19, 2016 at 11:05 PM, Jean-Philippe André  
> wrote:
>> Hi,
>>
>> On 19 December 2016 at 21:10, Gustavo Sverzut Barbieri 
>> wrote:
>>
>>> Hi all,
>>>
>>> In Efl.Net I've created couple of "constructors" functions to help the
>>> user with common tasks, such as:
>>>
>>
>> Hmm. Sorry to be pedantic, but you've created @class functions, not
>> constructor functions. :)
>>
>> src/lib/ecore_con/efl_net_ip_address.eo:
>>>
>>>- create(port, address)
>>>- create_sockaddr(sockaddr)
>>>- parse(string)
>>>- resolve(string, family, flags) (returns a promise)
>>>
>>> In many languages that's easy to use:
>>>
>>> efl.net.ip_address.create(1234, "127.0.0.1")
>>>
>>> But in C it's a bitch:
>>>
>>>efl_net_ip_address_create(EFL_NET_IP_ADDRESS_CLASS, 1234, "127.0.0.1");
>>>
>>
>> EO constructors would instead be used as follows:
>> efl_add(EFL_NET_IP_ADDRESS_CLASS, NULL, efl_net_ip_address_set(1234,
>> "127.0.0.1"));
>>
>> Not saying it looks any better, really. But that's what constructors are,
>> in EO.
>
> argh... my bad with naming conventions, how should we call what I
> meant? Creators? Factories?
>

Factories most likely.



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: static methods or C syntax sugar for class methods?

2016-12-20 Thread Gustavo Sverzut Barbieri 
On Mon, Dec 19, 2016 at 11:05 PM, Jean-Philippe André  wrote:
> Hi,
>
> On 19 December 2016 at 21:10, Gustavo Sverzut Barbieri 
> wrote:
>
>> Hi all,
>>
>> In Efl.Net I've created couple of "constructors" functions to help the
>> user with common tasks, such as:
>>
>
> Hmm. Sorry to be pedantic, but you've created @class functions, not
> constructor functions. :)
>
> src/lib/ecore_con/efl_net_ip_address.eo:
>>
>>- create(port, address)
>>- create_sockaddr(sockaddr)
>>- parse(string)
>>- resolve(string, family, flags) (returns a promise)
>>
>> In many languages that's easy to use:
>>
>> efl.net.ip_address.create(1234, "127.0.0.1")
>>
>> But in C it's a bitch:
>>
>>efl_net_ip_address_create(EFL_NET_IP_ADDRESS_CLASS, 1234, "127.0.0.1");
>>
>
> EO constructors would instead be used as follows:
> efl_add(EFL_NET_IP_ADDRESS_CLASS, NULL, efl_net_ip_address_set(1234,
> "127.0.0.1"));
>
> Not saying it looks any better, really. But that's what constructors are,
> in EO.

argh... my bad with naming conventions, how should we call what I
meant? Creators? Factories?


> While these are nice to be "class methods" since one could get these
>> to work with subclasses, they are often used with the original class.
>> Then my request is to either to introduce a "staticmethod" OR to use
>> some macro trick to count the number of parameters and pass the class
>> automatically when omitted or generate 2 functions, one with class and
>> another without (one could be an actual function, while the other just
>> a macro).
>>
>> End goal is to make these look more like:
>>
>> efl_net_ip_address_create(1234, "127.0.0.1");
>
>
> A macro could be nice. We still need @class functions to work with other
> classes than the one that declares the method. Each class can then have its
> own implementation of the common @class function. Should all sub
> implementations also provide a macro, then?

that's a neat idea, to generate the macros with the new name if "implements"

but if we do a macro that counts the number of parameters and if no
class is given it would assume the default class (base), that's easier
to use.

-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: static methods or C syntax sugar for class methods?

2016-12-19 Thread Jean-Philippe André 
Hi,

On 19 December 2016 at 21:10, Gustavo Sverzut Barbieri 
wrote:

> Hi all,
>
> In Efl.Net I've created couple of "constructors" functions to help the
> user with common tasks, such as:
>

Hmm. Sorry to be pedantic, but you've created @class functions, not
constructor functions. :)

src/lib/ecore_con/efl_net_ip_address.eo:
>
>- create(port, address)
>- create_sockaddr(sockaddr)
>- parse(string)
>- resolve(string, family, flags) (returns a promise)
>
> In many languages that's easy to use:
>
> efl.net.ip_address.create(1234, "127.0.0.1")
>
> But in C it's a bitch:
>
>efl_net_ip_address_create(EFL_NET_IP_ADDRESS_CLASS, 1234, "127.0.0.1");
>

EO constructors would instead be used as follows:
efl_add(EFL_NET_IP_ADDRESS_CLASS, NULL, efl_net_ip_address_set(1234,
"127.0.0.1"));

Not saying it looks any better, really. But that's what constructors are,
in EO.


While these are nice to be "class methods" since one could get these
> to work with subclasses, they are often used with the original class.
> Then my request is to either to introduce a "staticmethod" OR to use
> some macro trick to count the number of parameters and pass the class
> automatically when omitted or generate 2 functions, one with class and
> another without (one could be an actual function, while the other just
> a macro).
>
> End goal is to make these look more like:
>
> efl_net_ip_address_create(1234, "127.0.0.1");


A macro could be nice. We still need @class functions to work with other
classes than the one that declares the method. Each class can then have its
own implementation of the common @class function. Should all sub
implementations also provide a macro, then?

Best regards,

-- 
Jean-Philippe André
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel