Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add type parameter to ListModel and ListStore #213

Open
V02460 opened this issue Jul 27, 2021 · 1 comment · May be fixed by #609
Open

Add type parameter to ListModel and ListStore #213

V02460 opened this issue Jul 27, 2021 · 1 comment · May be fixed by #609
Labels
enhancement New feature or request

Comments

@V02460
Copy link

V02460 commented Jul 27, 2021

Each instance of ListStore and ListModel works on a concrete and fixed item type. Currently this is handled by checking and passing around a glib Type value. In Rust this can be expressed more elegantly by a type parameter. The big advantage is that there is no more fallible casting when using the different methods on these instances and Rust’s type system can be leveraged for e.g. type inference.

Before

struct ListStore;

fn new(item_type: glib::types::Type) -> Self;
fn append<P: IsA<glib::Object>>(&self, item: &P);

After

struct ListStore<T: IsA<Object>>;

fn new() -> Self;
fn append<P: IsA<T>>(&self, item: &P);
@V02460 V02460 added the enhancement New feature or request label Jul 27, 2021
@sdroege
Copy link
Member

sdroege commented Jul 27, 2021

You'd need to add some API for casting between ListModel<T> and ListModel<U> too then, and either needs to make sure that the type is a supertype (not subtype!) of the model's item type.

I think this would improve the API considerably but it also means that the bindings can't be autogenerated anymore (nothing where ListModel or ListStore appears in the API).

@jf2048 jf2048 linked a pull request Mar 14, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants