This is just a bit annoying.
Is there any other way this could be done? Perhaps the UI specified during creation could be stored in a field of the struct, like this:
That way you wouldn't have to also specify this UI object to every single method you call on that object.
In fact this could be done in a non-breaking way by preserving the original methods which take the &UI argument, and simply deprecating them.
small semver note:
This library is still in version 0 ("rapid prototyping phase"), so you don't need to increment major for breaking changes. Anyone using this library should be doing iui = "~0.3.0" or similar. It is definitely possible to make version 0.4.0 a breaking change. Although deprecating methods now and then removing them in version 1.0.0 would be preferable.
This is just a bit annoying.
Is there any other way this could be done? Perhaps the UI specified during creation could be stored in a field of the struct, like this:
That way you wouldn't have to also specify this UI object to every single method you call on that object.
In fact this could be done in a non-breaking way by preserving the original methods which take the
&UIargument, and simply deprecating them.small semver note:
This library is still in version 0 ("rapid prototyping phase"), so you don't need to increment major for breaking changes. Anyone using this library should be doing
iui = "~0.3.0"or similar. It is definitely possible to make version 0.4.0 a breaking change. Although deprecating methods now and then removing them in version 1.0.0 would be preferable.