Hi, I think either proposal is reasonable.
In the case where "bool return on property set indicates success", this can be enforced in eolian since it's a combination of property+typereturn, and it can be documented (and expanded on automatically in doc generation) to be more descriptive for anyone reading the documentation. It seems to me that, from an intuitive perspective, this would already make sense to anyone at a glance anyway. As for having an error_return flag/type, this also seems fine from a functional and documentation perspective, though it feels a bit strange and not-intuitive to have a different keyword/return type specific to property set methods than is used for methods which return bool. Regards, Mike On Mon, Oct 21, 2019 at 12:01 PM Tom Hacohen <[email protected]> wrote: > > > On 21/10/2019 18:54, Xavi Artigas wrote: > >> > >> Maybe in general we need a way to mark a return/parameter as an error > >> indicator? It's just a half-baked thought, though maybe worth exploring. > >> > > > > There's already a couple of ideas on Phab in this direction: Add custom > > tags to Eolian ( https://phab.enlightenment.org/T8294 ) or use > Eina.Error > > instead of bool when the setter intends to actually return an error. > > To avoid breaking API in the second case, we could use a "lightweight > eina > > error" which is actually a boolean (as Marcel suggests). > > I just thought that if we could agree that setters returning bools always > > mean "error", we could avoid the extra complexity. > > Sure, though just a convention is not enough. You need to have them > properly marked so it can be enforced by Eolian and that people who are > writing (and reading!) these interfaces know this what it means. > > -- > Tom > > > > > Xavi > > > > > >> > >> -- > >> Tom > >> > >> On 21/10/2019 17:49, Xavi Artigas wrote: > >>> Hi people, > >>> > >>> We are encountering a problem when matching EO properties to C# > >> properties, > >>> since the C# ones cannot have a return value. > >>> > >>> We mostly use return values in EO property setters to indicate error > >>> conditions and this is pretty easily matched to C# by throwing an > >>> exception. We just need to know WHEN a returned bool from a setter > really > >>> means ERROR and when it is not. > >>> Currently, all property setters in our tree returning a bool use it to > >>> indicate an error, so it is just a matter of we all agreeing that in > the > >>> future this will always be the case (and documenting it). > >>> If we agree on this, then the C# bindings can start throwing exceptions > >> on > >>> setters returning FALSE (there's a patch ready, but I cannot access it > >>> right now). > >>> > >>> If nobody has anything against it, I'll land this patch in a week > >> (October > >>> 28th). > >>> > >>> Thanks! > >>> Xavi > >>> > >>> _______________________________________________ > >>> enlightenment-devel mailing list > >>> [email protected] > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>> > >> > >> > >> _______________________________________________ > >> enlightenment-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > _______________________________________________ > > enlightenment-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
