Page MenuHomePhabricator

Use proper Eolian syntax for default values instead of docs
ClosedPublic

Authored by segfaultxavi on Sep 20 2019, 7:26 AM.

Details

Summary

Eolian supports reporting the defaults for parameters and return values, but in some
places we have been writing this information in the documentation instead.
This patch moves it to its proper place, where documentation generators can pick it up
and render it in a consistent manner.

Ref T8171

Diff Detail

Repository
rEFL core/efl
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
segfaultxavi created this revision.Sep 20 2019, 7:26 AM
segfaultxavi requested review of this revision.Sep 20 2019, 7:26 AM
lauromoura accepted this revision.Sep 20 2019, 7:54 AM
lauromoura added inline comments.
src/lib/efl/interfaces/efl_gfx_image.eo
217

Just a small typo (s/it/in/) that I will amend when pushing.

This revision is now accepted and ready to land.Sep 20 2019, 7:54 AM
This revision was automatically updated to reflect the committed changes.

@segfaultxavi

When we called "evas_object_propagate_events_get" with invalid Eo object, then it returned EINA_FALSE previously.
(Now, it gives EINA_TRUE because of its new default value when error cases).

Could we do something for this ?

I just added as default values what was written in the documentation.
After reading the code, I think the documentation for propagate_events was wrong and the default value was false.
However, I'd like the opinion of somebody with more experience... @cedric @zmike @bu5hm4n ?

@segfaultxavi
I also think - it would be better to have "true" as a default value for propagate property.
So, I hope there can be a proper way to keep it "false" only for legacy API calling.

@zmike @bu5hm4n @cedric
Do I need to check the validation of eo object and return the value properly in legacy API before calling new efl interface API ?
(if I want to return different value in the new efl interface APIs)

zmike added a comment.Sep 23 2019, 5:42 PM

@woohyun can you create a ticket for this? I think we will have to do something to enforce cases where the default legacy value is different from the eolian-generated default...

Specific to this case, I think the issue arises from the "default" value being different from the "value that is returned when there is an error". These are not the same concept, so we probably shouldn't treat them the same. I think any bool property should probably always return false on failure, regardless of the default.