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

[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?

[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?

[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?

[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?

[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

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

[Gustavo Sverzut Barbieri]

Hi all,

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

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");

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");


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

--
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