On 10/02/15 19:01, Davide Andreoli wrote:
> Hi,
> first of all... +1
> then my reply is based on the python experience and syntax.
>
> 2015-02-10 17:17 GMT+01:00 Tom Hacohen <[email protected]>:
>
>> Hey,
>>
>> Daniel and I are back to hacking on Eolian and we've again reached the
>> topic of nullability.
>>
>> In most correct cases, C pointers either point to a valid memory region,
>> or hold NULL. While NULL is valid for many APIs, it's not valid in
>> others (strlen() and etc.).
>> I can think of three examples of NULL in API:
>> 1. Pointers for multiple return values - size_get(&w, NULL), the second
>> one is an optional return value.
>>
>
> This api (a property) translate to python as:
> x, y, w, h = obj.geometry
> So there are no way to make one of the value optional, I think that
> @optional
> is an interesting tag, but you example is not the right one, we need
> a function, not a property.
Optional is for C (mostly as a documentation function). It's obviously
not relevant for python where you always return tuples.
>
>
>
>> 2. NULL is a valid value: part_text_set(NULL, "some text"), the NULL
>> means "use default".
>>
>
> This is another good example, if I'm not wrong, we hen have
> text_set("some text") that is a macro around part_text_set.
> We should avoid using macro (as we discussed yet) to simplify
> bindings generations. In this case I think we should just have 2
> different functions:
> text_set("some txt")
> part_text_set("part" @notnull, "some text")
I dislike the two functions, a waste of code. Nullable is a much cleaner
solution for C. Not sure about how we can do it for python (and other
languages that require the last part to be optional). Anyhow, this
specific example is moot, as we are going to kill off all the part_
functions (more on that in the future, don't worry, not going to lose
functionality).
>
>
>> 3. NULL is not allowed: strlen().
>>
>> For 1 we suggest having @optional, which indicates optional values
>> (similar to what they do in gobject land).
>>
>
> Dunno how gobject manage that, but in python, if we wan to support
> the @optional tag then all the optionals must be at the end of the params
> list, example:
> function(param1, param2, param3 @optional, param4 @optional) is good
> while:
> function(param1, param2 @optional, param3, param4) is not
> really translatable in py... Or at least I dunno how to implement that
Again, optional is for C, not python. For the python optionals we have
the "default value" way of setting a default value.
>
>
>
>> For 2 we suggest @nullable, indicating null is a valid value.
>> And 3 is the default.
>>
>
> No strong opinion on @nullable, only think I can say is that in
> python/cython we can use "not None" keyword to say that a
> param cannot be null, not the contrary. So it would be more
> convenient to have @notnull instead.
The question is if NULL is valid in more cases than not. I think the
answer to that is no. I.e we'll have to use @nullable much less than if
we'd have to use @notnull. At least that's what I think judging by my
"feel" of the API. It doesn't really matter for you, as you can generate
the python equivalent from either.
--
Tom.
>
>
>>
>> This works great, until you consider that in EFL land, we like using
>> EINA_ARG_NONNULL(). EINA_ARG_NONNULL() is a macro for decorating
>> function parameters, and is actually a wrapper around a gcc attribute
>> "nonnull". This attribute is great because it decorates the parameters
>> in ways that can help static analysers understand our code and find
>> error cases, and adds compiler warnings for obvious things (like passing
>> NULL). However, the problem with this attribute is that according to the
>> GCC manual:
>> "The compiler may also choose to make optimizations based on the
>> knowledge that certain function arguments will not be null."[1]
>> Which means it's possible it'll remove our runtime checks, which is a
>> price we are not willing to pay. This essentially means that decorating
>> our API with this is dangerous and should be avoided. This notion is not
>> new, this is something we've discussed in the past, and I think now that
>> we are cleaning the why we define our API, it's time to mention it
>> again. This attribute is not safe and should be avoided.
>> Bottom line, I'd like us to stop using EINA_ARG_NONULL, and to inform
>> you we plan on not using it in generated Eolian headers any more.
>>
>> I'm sending this email because I'd like to see what you think about the
>> suggestion for eolian (@optional and @nullable) and the idea of dropping
>> EINA_ARG_NONULL given that it's unsafe and can result in removed safety
>> checks.
>>
>> No need to reply with +1, I don't care for votes of support, only
>> arguments against (and arguments for if arguments against are raised).
>> We are going to implement @optional and @nullable anyway (can be removed
>> if someone finds them stupid), so it's mostly about the nonnull part.
>>
>> Thanks,
>> Tom.
>>
>> Reference:
>> [1] https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> enlightenment-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
