-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Field types created by impl_singleton! are opaque #15
Comments
RFC 2524 should fix this. |
Yet another layer of hack on this macro. Yuck. But without a fix for #15 or an alternative to make_widget! (which is the only way to use grid layouts) we have no choice.
Since this issue was created, the |
Note: this is still an issue, but the macro in question has been renamed to |
As an experiment, tried using let ty = make_ident(format_args!("{singleton_ty}{}", &ty_name[1..]), span);
pre_items.append_all(quote! { type #ty = impl #bound; });
// or, for widgets with omitted type:
pre_items.append_all(quote! { type #ty = impl ::kas::Widget; }); The result appears to function identically (except where there are zero bounds, but such fields are only useful for extending the life of some object). It does not solve the issue of opaque types, nor offers any other advantage. |
When creating a widget with
make_widget!{ .. }
, fields cannot be accessed from outside the defining macro due to the anonymous type.I had hoped this could be fixed with some type of type alias feature, but alas, this appears limited to trait implementations.
To some extent this can be worked around with traits, e.g. from the
stopwatch
example:allowing
self.display.set_text(tk, &self.dur_buf);
to be called from the outer widget later.Ideally in the above, it would be possible to directly call
self.display.display.set_text(tk, ..)
.Proposal:
build_widget!
macroMove most of the
make_widget!
code into a separate macro, defining the type, and allow direct use of this.Issue: implicit typing within
make_widget!
uses generics, thus the resulting type requires parameterisation on use. Ideally, we would not have to use generics but could use some type of "magic type alias".The text was updated successfully, but these errors were encountered: