Function Conventions
Opened this issue · 2 comments
Some conventions on the functions must be discussed...
Null parameters
Some functions allow null pointers to be passed to them.. For instance IupInsert
and IupReparent
allow the ref_child
parameter to be NULL essentially making the first found child to be used as the ref_child.
Currently our binding enforces the passing of ref_child
(i.e. it's not a Option).
fn insert<E1, E2>(&mut self, ref_child: &E1, new_child: E2) -> Result<Handle, E2>
where E1: Element, E2: Element {
The thing is, if it was a Option, passing None
as parameter would bring a error that it does not know enough about E1
constraint and thus we'd need to specify it explicitly (e.g. None::<Handle>
) and that does not look quite beauty.
What should be done in such cases?
There is also this other related on Dialogs:
pub fn new<E: Element>(child: E) -> Dialog
pub fn new_empty() -> Dialog
Didn't use a single new
with a Option parameter for that very same reason.
And that brings us to another issue.
Constructor namings
Should we use a fn new<E: Element>(child: E) -> Dialog
or fn with<E: Element>(child: E) -> Dialog
or use a Option
(see previous topic)? The same question applies to layout boxes and other container objects.
If still new
without Option
should the empty version be named new_empty
?
As a side note, buttons (and other future controls?!) does it this way:
fn new() -> Button
fn with_title<S: Into<String>>(title: S) -> Button
fn with_image(image: ?) -> Button // in the future
Get/Set
Currently the library follows Rust guidelines of setters having a set_
prefix and getters having no prefix (e.g. set_attrib
sets and attrib
gets, parent
instead of get_parent
and so on), that seems the way to go but if there's any contradiction to it please enlighten me.
Result
Since IUP does not give any manner of a descriptive error message (with strings), we shouldn't perhaps be returning Result<T, String>
mainly in the cases only IUP_NOERROR
and IUP_ERROR
are possible.
We should be using Result<T, ()>
(or anything along those lines) for the case where there can be only one single error (e.g. IUP_ERROR
) and use a Result<T, Enum
in cases it may return different error types (i.e. with_iup
).
Another issue with strings is that they cannot be matched to easily find out what happened wrong in the multi-error case.
/cc @dcampbell24
Regarding Result
Result<Self, Self>
could be used where applicabe and so on.show
and showxy
are returning Result<(), String
to be able to forward to the result type of f
in with_iup
.