You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off Amazing library!. I stumbled upon it when writing my own proc macros to try a similar goal, so very happy a much better solution already existed.
One thing I've noticed that access to the nested states and values typically does seem to be accessible.
Most examples also have the inner 'states' having public variables, so these end up being accessible too.
In btrepp@eb92c15 I was able to remove pub, and fix examples to work. The biggest trick is making the implementations of the trait to be inside the mod itself, thus allowing access to any struct field without declaring them pub. This seems to keep everything nice and hidden, meaning we can only use our public apis to interact with the typestate machines. The downside is trait impls must be inside the mod block, which isn't as nice. There may be ways of working around that using a function macro instead of an attribute one.
I didn't open this as a PR yet, as perhaps there are valid reasons to have the inner state accessible, but at a glance I feel like the pattern should be forcing API consumers to follow the state transitions, and hiding it's inner properties.
Hello @btrepp! Glad to know that you found my crate interesting (I've spent a long time on it).
To provide you with a brief answer, the inner state can carry data thus I made it pub by default.
In a more complete reply - I agree that the inner data could be private, ideally, the user should have full control over it.
Addressing your impl idea. I have nothing against it. In fact, I wanted to do that from the begining. However, it raises some questions:
What happens with functions? Should they return State or Automaton<State>?
And "meat" of the functions? How can they return the correct type with minimal impact for the user?
To materialize what I was talking about:
traitS{fnnew() -> S;}implSforAutomaton<S>{// The signatures don't match pre-expansion and this might be confusing// One can also expand them so we could simply have // ```// impl S { ... }// ```// But then the question is, what about the inside function?// How can the user *easily* return a valid `Automaton<S>`?fnnew() -> Automaton<S>{// ...}}
First off Amazing library!. I stumbled upon it when writing my own proc macros to try a similar goal, so very happy a much better solution already existed.
One thing I've noticed that access to the nested states and values typically does seem to be accessible.
This comes from
typestate-rs/typestate-proc-macro/src/visitors/state.rs
Line 210 in 83b0ef0
Most examples also have the inner 'states' having public variables, so these end up being accessible too.
In btrepp@eb92c15 I was able to remove pub, and fix examples to work. The biggest trick is making the implementations of the trait to be inside the mod itself, thus allowing access to any struct field without declaring them pub. This seems to keep everything nice and hidden, meaning we can only use our public apis to interact with the typestate machines. The downside is trait impls must be inside the mod block, which isn't as nice. There may be ways of working around that using a function macro instead of an attribute one.
I didn't open this as a PR yet, as perhaps there are valid reasons to have the inner state accessible, but at a glance I feel like the pattern should be forcing API consumers to follow the state transitions, and hiding it's inner properties.
Cargo expand on main lightbulb example
Cargo expand on my fork that changes
pub state: State
tostate:State
The text was updated successfully, but these errors were encountered: