-
Notifications
You must be signed in to change notification settings - Fork 13
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
Wrapper classes StatePost, and for initial and final states sets? #325
Comments
@kilohsakul @jurajsic @tfiedor @vhavlena Any opinions? |
I would probably not implement these wrappers. It is a lot of work and code and will only complicate the interface. |
Would the wrapper be useful in some way? Because I don't really see it |
I would keep the things as simple as possible. I see it as a complication, which is not so beneficial to me now. |
Unless we plan on somehow extending the wrappers in the future (with methods named specifically for states, etc.), the wrapper is useless in my opinion. The only advantage in the current stage would be getting a number of states would be consistent with |
Sadly, I don't really care about this. |
No one sees a reason for the wrappers. We will keep the types as they are now. I will close this issue as resolved, then. |
Question originally raised in #277 (comment).
They will have to be unless you want to create a wrapper class
SparseStateSet
. It would have a memberSparseSet
, methodnum_of_states()
which would only callreturn this->sparse_set.size();
and add the boilerplate code for all other functions unmodified, as what we intend to do forStatePost
.However, if we do this for
StatePost
, we could create the wrapper for sparse set, too. It is the same wrapper asStatePost
is forOrdVector<SymbolPost>
. Opinions?The text was updated successfully, but these errors were encountered: