Function Conventions

[thelink2012]

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.

[thelink2012]

/cc @dcampbell24

[thelink2012]

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.