Re: [E-devel] Eo API parameter nullability
Hello, On Wed, Nov 19, 2014 at 1:13 PM, Tom Hacohen wrote: > On 05/11/14 19:28, Felipe Magno de Almeida wrote: >> I chatted with TAsn and q66 on IRC on 'parameter nullability'. What do >> I mean by that? >> >> elm_widget_part_text_set(widget, NULL, "set this text to the default part"); >> >> The thing is, some languages that are being bound to EFL don't have a >> NULL value for all objects or references. Which means that to be able >> to pass NULL we have to have some kind of workaround, like a >> optional in C++. >> >> This is all cool and all. However, we need to tag these parameters so >> we don't have optional all over the place where it is not meant to be >> nullable. So, Eo has a tag named @nonull which means that that >> specific parameter can't receive NULL. However, it means nullability >> is the default. I was discussing if maybe we should drop @nonull and >> use @null to tag nullability with non-nullability as default. Because >> we don't want to be able to pass NULL pointers to parameters that >> mistakenly gets tagged as nullable. IOW, have a more strict default. >> >> This change, however, might not seem so inviting because it might be a >> mental shift for some people. So well, I'm in favor of the change >> because I think it will have less accidental flags for nullability and >> makes the bindings cleaner. However, this must be discussed because it >> impacts all API for EFL. >> >> So, what is your take? Should we have nullable parameters as default >> or non-nullable? >> >> Best regards, >> > > Sorry for the belated reply, I was AFK on holiday. :) > > Anyhow, as I said on IRC, it's not that simple. First of all, @nonull > has implications for C as well, it sets the compiler attributes. This > compile attribute triggers warnings for users of the API, but also > causes optimizations. That is, setting an arg as nonull means the burden > of checking is on the user of the API, not the API itself. At least, > that's what I remember from the last time we talked about parameter > nullability and this attribute. > This means that nonull should be used carefully and surgically, only > when applicable, though to be honest, we should maybe drop this > attribute altogether (for C), as we check everywhere anyway. No, we don't. That's why we use it. That's specially true in Eina, not so much in other library. > If we stop using the C attribute, I'm in favour of using @null they way > you've described, if we don't, it's a definite no to this change, as > it'll break things all over the place. Or we could introduce a tests suite that test with NULL :-D Sorry for that bad joke... -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
On 05/11/14 19:28, Felipe Magno de Almeida wrote: > Hello, > > I chatted with TAsn and q66 on IRC on 'parameter nullability'. What do > I mean by that? > > elm_widget_part_text_set(widget, NULL, "set this text to the default part"); > > The thing is, some languages that are being bound to EFL don't have a > NULL value for all objects or references. Which means that to be able > to pass NULL we have to have some kind of workaround, like a > optional in C++. > > This is all cool and all. However, we need to tag these parameters so > we don't have optional all over the place where it is not meant to be > nullable. So, Eo has a tag named @nonull which means that that > specific parameter can't receive NULL. However, it means nullability > is the default. I was discussing if maybe we should drop @nonull and > use @null to tag nullability with non-nullability as default. Because > we don't want to be able to pass NULL pointers to parameters that > mistakenly gets tagged as nullable. IOW, have a more strict default. > > This change, however, might not seem so inviting because it might be a > mental shift for some people. So well, I'm in favor of the change > because I think it will have less accidental flags for nullability and > makes the bindings cleaner. However, this must be discussed because it > impacts all API for EFL. > > So, what is your take? Should we have nullable parameters as default > or non-nullable? > > Best regards, > Sorry for the belated reply, I was AFK on holiday. :) Anyhow, as I said on IRC, it's not that simple. First of all, @nonull has implications for C as well, it sets the compiler attributes. This compile attribute triggers warnings for users of the API, but also causes optimizations. That is, setting an arg as nonull means the burden of checking is on the user of the API, not the API itself. At least, that's what I remember from the last time we talked about parameter nullability and this attribute. This means that nonull should be used carefully and surgically, only when applicable, though to be honest, we should maybe drop this attribute altogether (for C), as we check everywhere anyway. If we stop using the C attribute, I'm in favour of using @null they way you've described, if we don't, it's a definite no to this change, as it'll break things all over the place. -- Tom. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
On Thu, 6 Nov 2014 20:01:45 -0200 Felipe Magno de Almeida
said:
> On Thu, Nov 6, 2014 at 6:45 PM, Davide Andreoli
> wrote:
> > 2014-11-06 3:59 GMT+01:00 Carsten Haitzler :
> >
> >> On Wed, 5 Nov 2014 23:42:46 -0300 Vinícius dos Santos Oliveira
> >> said:
> >>
> >> > 2014-11-05 23:40 GMT-03:00 Carsten Haitzler :
> >> >
> >> > > oh shit - yes. you're right. the other way around. maybe not @null but
> >> > > @skipnull ? ie it means IF this parameter is NULL, it's skipped
> >> (ignored).
> >> > > this
> >> > > then does nicely imply that the param can be made optional in langs
> >> that
> >> > > support it (as without the param being a valid thing - eg not NULL, it
> >> is
> >> > > ignored/skipped and thus can be optional).
> >> >
> >> >
> >> > This is the opposite of intuitive and it required you a full paragraph to
> >> > describe it.
> >>
> >> and @null .. says what? that this parameter is always null?
> >>
> >> @skipnull - SKIP parameter if NULL
> >>
> >
> > What do you mean by "skip" a parameter ? you mean that the user can fully
> > omit the param?
> >
> > for example the user can use:
> > elm_widget_part_text_set(widget, "set this text to the default part")
> > and the bindings automatically add the @null missing param?
> >
> > I don't think this is really practicable, if there are more than one
> > nullable params in a function
> > the bindings cannot know what param the user would like to skip...
>
> For C++ it would work something like this:
>
> widget.part_text_set(efl::eina::none, "set this text to the default part");
>
> So no skipping. And for C it would happen as already is:
i thought you wanted to do polymorphism with:
obj.part_text_set("partname", "text");
and
obj.part_text_set("text");
when we only have 1 string... the part is assumed to be NULL.
> elm_widget_part_text_set(widget, NULL, "set this text to the default part");
>
> The point of the email is just to decide which is the best default
> for marking parameters as nullable. Are they nullable by default
> or are they _not_ nullable by default?
currently ALL params cn be NULL unless indicated with EINA_NONNULL in the old c
bindings (@nonull is that ported over). we've done it this way for a long time
now. i thought you wanted to literally drop the argument as a way of "assuming"
it's NULL.
> > In python this could be solved using named params, for example:
> > widget.part_text_set(text="blah blah")
> > and the bindings can automatically add the missing "part" params,
> > but I'm not sure if this can be implemented in other languages.
thats what i was thinking too. for c++ use polymorphism, for pyhton, lua (not
sure on js) use named parameters.
> This is actually very useful for python then.
>
> > I also don't understand how the @null tag can help c++ bindings,
> > letting the user omit a NULL param?
>
> The point is not omitting it, but being able to pass a value that
> is null. Which is not possible for most values (e.g, strings), so
> the parameter type must change for parameters that are @null.
i'm curious - how is it not possible? you could just have a base eo.null or
something (#define this somewhere in the bindings to null or none or whatever).
detect if the obj passed == eo.null then pass NULL to c.
> > what if a function have 3 nullable string params
> > and the user provide only one of those? witch of the 3 is the one the user
> > provided?
>
> It works the same @null and @nonull, it just a matter of which
> is the default. So for your case it is:
>
> jurubeba.foobar(none, "set this text to the default part", none, none);
>
> And the C++ code will call:
>
> jurubeba_foobar(jurubeba, NULL, "set this text to the default part",
> NULL, NULL);
>
> Without marking them @null the user will have to provide a value
> that is consistent with the parameter type.
>
> jurubeba.foobar("", "set this text to the default part", "", "");
>
> Which will be equivalent to:
>
> jurubeba_foobar(jurubeba, "", "set this text to the default part", "", "");
>
> As most things in C++, named paraters are implementable in C++,
> but I don't really think it is useful to go this route.
> (e.g, boost.parameter)
>
> Regards,
> --
> Felipe Magno de Almeida
>
> --
> ___
> 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
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
On Thu, 6 Nov 2014 20:06:48 -0200 Felipe Magno de Almeida said: > Hello raster, > > On Thu, Nov 6, 2014 at 12:40 AM, Carsten Haitzler > wrote: > > On Wed, 5 Nov 2014 22:52:10 -0200 Felipe Magno de Almeida > > said: > > > >> On Wed, Nov 5, 2014 at 10:17 PM, Carsten Haitzler > >> wrote: > >> > On Wed, 5 Nov 2014 17:28:56 -0200 Felipe Magno de Almeida > >> > said: > >> > > >> > i'm in favor of "as it stands right now". why? if we explicitly make > >> > something nullable to have it there, bindings will be able to drop ALL > >> > parameters i don't mark as @null - they are all optional. and that's a > >> > really unexpected behavior AND adds a lot of work adding all the @nulls > >> > everywhere. > >> > >> I think it is the other way isn't it? If you have to mark as @null for > >> it to accept NULL, it means the binding MUST not make it > >> optional unless I really do use @null. Right now @null is > >> implied, which means almost everything is @null. But I > >> doubt almost everything is really optional (= can pass > >> NULL). Also, the bindings can't really drop anything, the @null > >> just means the user can pass a value meaning no-value > >> (i.e, NULL). Otherwise the user must pass a real value (not NULL). > >> This makes a difference in C++ because I can't really pass > >> NULL for a string for example. > >> > >> Or am I missing something? > > > > oh shit - yes. you're right. the other way around. maybe not @null but > > @skipnull ? ie it means IF this parameter is NULL, it's skipped (ignored). > > this then does nicely imply that the param can be made optional in langs > > that support it (as without the param being a valid thing - eg not NULL, it > > is ignored/skipped and thus can be optional). > > What I mean with @null is that the parameter accepts NULL values. > This is important because most values can't be NULL in C++. So in the c apis most params can be NULL. thus why it's the default unless tagged @nonull. > I really don't know which parameter to use for the wrapper in case, > for example, of a const char* parameter. It is a string, but can this > string be NULL? A NULL value is not a string in any sense for C++. > So if a parameter allow for NULL values, C++ has to use a different > type that accepts a string _and_ accepts a value that denotes > NULL. > > The thing is that today, in eolian, @null is implied for all pointer > types (including strings) and if something can't be NULL it > must be tagged as @nonull. My question is: which should be > implied, i.e, default? Parameters that can be NULL or > parameters that can _not_ be NULL? > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > Kind regards, > -- > Felipe Magno de Almeida > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
Hello raster, On Thu, Nov 6, 2014 at 12:40 AM, Carsten Haitzler wrote: > On Wed, 5 Nov 2014 22:52:10 -0200 Felipe Magno de Almeida > said: > >> On Wed, Nov 5, 2014 at 10:17 PM, Carsten Haitzler >> wrote: >> > On Wed, 5 Nov 2014 17:28:56 -0200 Felipe Magno de Almeida >> > said: >> > >> > i'm in favor of "as it stands right now". why? if we explicitly make >> > something nullable to have it there, bindings will be able to drop ALL >> > parameters i don't mark as @null - they are all optional. and that's a >> > really unexpected behavior AND adds a lot of work adding all the @nulls >> > everywhere. >> >> I think it is the other way isn't it? If you have to mark as @null for >> it to accept NULL, it means the binding MUST not make it >> optional unless I really do use @null. Right now @null is >> implied, which means almost everything is @null. But I >> doubt almost everything is really optional (= can pass >> NULL). Also, the bindings can't really drop anything, the @null >> just means the user can pass a value meaning no-value >> (i.e, NULL). Otherwise the user must pass a real value (not NULL). >> This makes a difference in C++ because I can't really pass >> NULL for a string for example. >> >> Or am I missing something? > > oh shit - yes. you're right. the other way around. maybe not @null but > @skipnull ? ie it means IF this parameter is NULL, it's skipped (ignored). > this > then does nicely imply that the param can be made optional in langs that > support it (as without the param being a valid thing - eg not NULL, it is > ignored/skipped and thus can be optional). What I mean with @null is that the parameter accepts NULL values. This is important because most values can't be NULL in C++. So I really don't know which parameter to use for the wrapper in case, for example, of a const char* parameter. It is a string, but can this string be NULL? A NULL value is not a string in any sense for C++. So if a parameter allow for NULL values, C++ has to use a different type that accepts a string _and_ accepts a value that denotes NULL. The thing is that today, in eolian, @null is implied for all pointer types (including strings) and if something can't be NULL it must be tagged as @nonull. My question is: which should be implied, i.e, default? Parameters that can be NULL or parameters that can _not_ be NULL? > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > Kind regards, -- Felipe Magno de Almeida -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
On Thu, Nov 6, 2014 at 6:45 PM, Davide Andreoli wrote:
> 2014-11-06 3:59 GMT+01:00 Carsten Haitzler :
>
>> On Wed, 5 Nov 2014 23:42:46 -0300 Vinícius dos Santos Oliveira
>> said:
>>
>> > 2014-11-05 23:40 GMT-03:00 Carsten Haitzler :
>> >
>> > > oh shit - yes. you're right. the other way around. maybe not @null but
>> > > @skipnull ? ie it means IF this parameter is NULL, it's skipped
>> (ignored).
>> > > this
>> > > then does nicely imply that the param can be made optional in langs
>> that
>> > > support it (as without the param being a valid thing - eg not NULL, it
>> is
>> > > ignored/skipped and thus can be optional).
>> >
>> >
>> > This is the opposite of intuitive and it required you a full paragraph to
>> > describe it.
>>
>> and @null .. says what? that this parameter is always null?
>>
>> @skipnull - SKIP parameter if NULL
>>
>
> What do you mean by "skip" a parameter ? you mean that the user can fully
> omit the param?
>
> for example the user can use:
> elm_widget_part_text_set(widget, "set this text to the default part")
> and the bindings automatically add the @null missing param?
>
> I don't think this is really practicable, if there are more than one
> nullable params in a function
> the bindings cannot know what param the user would like to skip...
For C++ it would work something like this:
widget.part_text_set(efl::eina::none, "set this text to the default part");
So no skipping. And for C it would happen as already is:
elm_widget_part_text_set(widget, NULL, "set this text to the default part");
The point of the email is just to decide which is the best default
for marking parameters as nullable. Are they nullable by default
or are they _not_ nullable by default?
> In python this could be solved using named params, for example:
> widget.part_text_set(text="blah blah")
> and the bindings can automatically add the missing "part" params,
> but I'm not sure if this can be implemented in other languages.
This is actually very useful for python then.
> I also don't understand how the @null tag can help c++ bindings,
> letting the user omit a NULL param?
The point is not omitting it, but being able to pass a value that
is null. Which is not possible for most values (e.g, strings), so
the parameter type must change for parameters that are @null.
> what if a function have 3 nullable string params
> and the user provide only one of those? witch of the 3 is the one the user
> provided?
It works the same @null and @nonull, it just a matter of which
is the default. So for your case it is:
jurubeba.foobar(none, "set this text to the default part", none, none);
And the C++ code will call:
jurubeba_foobar(jurubeba, NULL, "set this text to the default part",
NULL, NULL);
Without marking them @null the user will have to provide a value
that is consistent with the parameter type.
jurubeba.foobar("", "set this text to the default part", "", "");
Which will be equivalent to:
jurubeba_foobar(jurubeba, "", "set this text to the default part", "", "");
As most things in C++, named paraters are implementable in C++,
but I don't really think it is useful to go this route.
(e.g, boost.parameter)
Regards,
--
Felipe Magno de Almeida
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
2014-11-06 3:59 GMT+01:00 Carsten Haitzler : > On Wed, 5 Nov 2014 23:42:46 -0300 Vinícius dos Santos Oliveira > said: > > > 2014-11-05 23:40 GMT-03:00 Carsten Haitzler : > > > > > oh shit - yes. you're right. the other way around. maybe not @null but > > > @skipnull ? ie it means IF this parameter is NULL, it's skipped > (ignored). > > > this > > > then does nicely imply that the param can be made optional in langs > that > > > support it (as without the param being a valid thing - eg not NULL, it > is > > > ignored/skipped and thus can be optional). > > > > > > This is the opposite of intuitive and it required you a full paragraph to > > describe it. > > and @null .. says what? that this parameter is always null? > > @skipnull - SKIP parameter if NULL > What do you mean by "skip" a parameter ? you mean that the user can fully omit the param? for example the user can use: elm_widget_part_text_set(widget, "set this text to the default part") and the bindings automatically add the @null missing param? I don't think this is really practicable, if there are more than one nullable params in a function the bindings cannot know what param the user would like to skip... In python this could be solved using named params, for example: widget.part_text_set(text="blah blah") and the bindings can automatically add the missing "part" params, but I'm not sure if this can be implemented in other languages. I also don't understand how the @null tag can help c++ bindings, letting the user omit a NULL param? what if a function have 3 nullable string params and the user provide only one of those? witch of the 3 is the one the user provided? > > > -- > > Vinícius dos Santos Oliveira > > https://about.me/vinipsmaker > > > -- > > ___ > > 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 > > > > -- > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
On Wed, 5 Nov 2014 23:42:46 -0300 Vinícius dos Santos Oliveira said: > 2014-11-05 23:40 GMT-03:00 Carsten Haitzler : > > > oh shit - yes. you're right. the other way around. maybe not @null but > > @skipnull ? ie it means IF this parameter is NULL, it's skipped (ignored). > > this > > then does nicely imply that the param can be made optional in langs that > > support it (as without the param being a valid thing - eg not NULL, it is > > ignored/skipped and thus can be optional). > > > This is the opposite of intuitive and it required you a full paragraph to > describe it. and @null .. says what? that this parameter is always null? @skipnull - SKIP parameter if NULL > -- > Vinícius dos Santos Oliveira > https://about.me/vinipsmaker > -- > ___ > 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 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
2014-11-05 23:40 GMT-03:00 Carsten Haitzler : > oh shit - yes. you're right. the other way around. maybe not @null but > @skipnull ? ie it means IF this parameter is NULL, it's skipped (ignored). > this > then does nicely imply that the param can be made optional in langs that > support it (as without the param being a valid thing - eg not NULL, it is > ignored/skipped and thus can be optional). This is the opposite of intuitive and it required you a full paragraph to describe it. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
On Wed, 5 Nov 2014 22:52:10 -0200 Felipe Magno de Almeida said: > On Wed, Nov 5, 2014 at 10:17 PM, Carsten Haitzler > wrote: > > On Wed, 5 Nov 2014 17:28:56 -0200 Felipe Magno de Almeida > > said: > > > > i'm in favor of "as it stands right now". why? if we explicitly make > > something nullable to have it there, bindings will be able to drop ALL > > parameters i don't mark as @null - they are all optional. and that's a > > really unexpected behavior AND adds a lot of work adding all the @nulls > > everywhere. > > I think it is the other way isn't it? If you have to mark as @null for > it to accept NULL, it means the binding MUST not make it > optional unless I really do use @null. Right now @null is > implied, which means almost everything is @null. But I > doubt almost everything is really optional (= can pass > NULL). Also, the bindings can't really drop anything, the @null > just means the user can pass a value meaning no-value > (i.e, NULL). Otherwise the user must pass a real value (not NULL). > This makes a difference in C++ because I can't really pass > NULL for a string for example. > > Or am I missing something? oh shit - yes. you're right. the other way around. maybe not @null but @skipnull ? ie it means IF this parameter is NULL, it's skipped (ignored). this then does nicely imply that the param can be made optional in langs that support it (as without the param being a valid thing - eg not NULL, it is ignored/skipped and thus can be optional). -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
On Wed, 5 Nov 2014 17:28:56 -0200 Felipe Magno de Almeida said: i'm in favor of "as it stands right now". why? if we explicitly make something nullable to have it there, bindings will be able to drop ALL parameters i don't mark as @null - they are all optional. and that's a really unexpected behavior AND adds a lot of work adding all the @nulls everywhere. > Hello, > > I chatted with TAsn and q66 on IRC on 'parameter nullability'. What do > I mean by that? > > elm_widget_part_text_set(widget, NULL, "set this text to the default part"); > > The thing is, some languages that are being bound to EFL don't have a > NULL value for all objects or references. Which means that to be able > to pass NULL we have to have some kind of workaround, like a > optional in C++. > > This is all cool and all. However, we need to tag these parameters so > we don't have optional all over the place where it is not meant to be > nullable. So, Eo has a tag named @nonull which means that that > specific parameter can't receive NULL. However, it means nullability > is the default. I was discussing if maybe we should drop @nonull and > use @null to tag nullability with non-nullability as default. Because > we don't want to be able to pass NULL pointers to parameters that > mistakenly gets tagged as nullable. IOW, have a more strict default. > > This change, however, might not seem so inviting because it might be a > mental shift for some people. So well, I'm in favor of the change > because I think it will have less accidental flags for nullability and > makes the bindings cleaner. However, this must be discussed because it > impacts all API for EFL. > > So, what is your take? Should we have nullable parameters as default > or non-nullable? > > Best regards, > -- > Felipe Magno de Almeida > > -- > ___ > 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 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
On Wed, Nov 5, 2014 at 10:17 PM, Carsten Haitzler wrote: > On Wed, 5 Nov 2014 17:28:56 -0200 Felipe Magno de Almeida > said: > > i'm in favor of "as it stands right now". why? if we explicitly make something > nullable to have it there, bindings will be able to drop ALL parameters i > don't > mark as @null - they are all optional. and that's a really unexpected behavior > AND adds a lot of work adding all the @nulls everywhere. I think it is the other way isn't it? If you have to mark as @null for it to accept NULL, it means the binding MUST not make it optional unless I really do use @null. Right now @null is implied, which means almost everything is @null. But I doubt almost everything is really optional (= can pass NULL). Also, the bindings can't really drop anything, the @null just means the user can pass a value meaning no-value (i.e, NULL). Otherwise the user must pass a real value (not NULL). This makes a difference in C++ because I can't really pass NULL for a string for example. Or am I missing something? Regards, -- Felipe Magno de Almeida -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API parameter nullability
Hello, On Wed, Nov 5, 2014 at 8:28 PM, Felipe Magno de Almeida wrote: > I chatted with TAsn and q66 on IRC on 'parameter nullability'. What do > I mean by that? > > elm_widget_part_text_set(widget, NULL, "set this text to the default part"); > > The thing is, some languages that are being bound to EFL don't have a > NULL value for all objects or references. Which means that to be able > to pass NULL we have to have some kind of workaround, like a > optional in C++. > > This is all cool and all. However, we need to tag these parameters so > we don't have optional all over the place where it is not meant to be > nullable. So, Eo has a tag named @nonull which means that that > specific parameter can't receive NULL. However, it means nullability > is the default. I was discussing if maybe we should drop @nonull and > use @null to tag nullability with non-nullability as default. Because > we don't want to be able to pass NULL pointers to parameters that > mistakenly gets tagged as nullable. IOW, have a more strict default. > > This change, however, might not seem so inviting because it might be a > mental shift for some people. So well, I'm in favor of the change > because I think it will have less accidental flags for nullability and > makes the bindings cleaner. However, this must be discussed because it > impacts all API for EFL. > > So, what is your take? Should we have nullable parameters as default > or non-nullable? I have no opinion on the matter, just if we do move forward with your proposition, please find a way to automate the change and check that the result is consistent with our current code. I am really afraid that we would mark some of our API in a wrong way. The one behind Eo won't be to affected I guess, but maybe in some case the compiler will take action and simplify code marked as NONNULL. That could lead to bugs. -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Eo API parameter nullability
Hello, I chatted with TAsn and q66 on IRC on 'parameter nullability'. What do I mean by that? elm_widget_part_text_set(widget, NULL, "set this text to the default part"); The thing is, some languages that are being bound to EFL don't have a NULL value for all objects or references. Which means that to be able to pass NULL we have to have some kind of workaround, like a optional in C++. This is all cool and all. However, we need to tag these parameters so we don't have optional all over the place where it is not meant to be nullable. So, Eo has a tag named @nonull which means that that specific parameter can't receive NULL. However, it means nullability is the default. I was discussing if maybe we should drop @nonull and use @null to tag nullability with non-nullability as default. Because we don't want to be able to pass NULL pointers to parameters that mistakenly gets tagged as nullable. IOW, have a more strict default. This change, however, might not seem so inviting because it might be a mental shift for some people. So well, I'm in favor of the change because I think it will have less accidental flags for nullability and makes the bindings cleaner. However, this must be discussed because it impacts all API for EFL. So, what is your take? Should we have nullable parameters as default or non-nullable? Best regards, -- Felipe Magno de Almeida -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
