Re: [boost] [msm] Review
Hi Darryl, If you don't mind, I'll start by answering the last question, it'll make the rest of the discussion easier.
Now I'm confused. Are you:
a) Convinced the suggestion is without merit?
No. After reading your last mail, I see a bit better, though I'm not sure I can follow all of it.
b) Waiting for a concrete example?
Yes! Exactly.
c) Convinced I'm an idiot that can't figure out how to use msm effectively (in which case, consider this a request for better docs)?
No. Sorry if I gave you the feeling the correct answer was a) or b). I don't mind criticism, any of it, justified or not, as long as it doesn't stay vague and instead goes to concrete, argumented points. Vague negative comments bring little to the review and contribute to giving an incomfortable feeling to all participants. Constructive remarks are, on the other side, highly welcome! That's reason #1 for a review. I sometimes, like yesterday, take part in several parallel discussions, so I have little time left for remarks I cannot start anything with. Sorry about it, it's the negative side of the review. I'd be thankful if potentially useful but vague ideas were kept for a more quiet time. So now, to the concrete parts of your remarks.
I genuinely don't see why msm needs to instantiate state objects it owns at all.
If this is the point, then it is a solvable problem. Clearly, it doesn't strictly need. It's just a feature, which is in some contexts very useful. The main one is to be able to save some data in the states. This data can then be generically accessed by the generic functors, thus increasing reuse and encouraging clean code. The functor front-end will be your friend in this case. The same with eUML, but it doesn't have to be eUML. The second reason would be entry/exit:
I suggest spelling them enter<state>(machine) and exit<state>(machine) or machine.enter<state>() and machine.exit<state>().
Of course, this would be a solution. It's actually an interesting one, and if you don't mind, we'll keep for later (see below). Do we agree that it makes the machine slightly less readable? The 3rd reason is state reuse. This brings us to:
What does reuse of a state in msm mean?
Interesting question, which is sadly ignored by many fsm frameworks. A case would be when you want to avoid doing the same case again and again. You could then define a state hierarchy, even (gulps) OO-like for this (or better some template policy magic). For example, I personally often add some logging in debug mode, so that I know what happened in my system. The visitor is another good example of it. I hope that after having a look at it, you'll see the interest you can gain from it. You might have easily missed another case in the doc. If you have a look at iPodSearch and iPodSearchEuml, you'll see where I want to go next. To states which implement STL algorithms. You will then be able to write complex algorithms by simply moving some predefined states on a diagram. I plan to call it the STL (State Template Library ;-) ). While this is for the future, I'll need independent, reusable states for it.
No. For the record, in my opinion, the single the worst feature of statechart is the necessity to use custom reactions to implement some fsm <constructs. This was a subject of much discussion during the Statechart (FSM) review iirc.
I see. Then I probably misunderstood your point.
Can you perhaps explain why flags are needed?
Sure. If you look at the statechart doc, you'll see some state_cast. I personally find it not beautiful in my code. It's also hard to maintain when your fsm structure changes. Flags are faster, require no rtti, are more model-oriented as states define themselves their "property" and makes user code easier/smaller to read. It's even supported by eUML for better model-orientation. I wanted to handle the entry/exit discussion separately. Hopefully I managed to convince you why states are useful and their instanciation brings some advantages. Of course, there is a price to pay, though a small one (if without data, 1 byte/state). This is in most cases not a huge cost. I agree there are cases where the price is still too expensive. I also agree, that the one current MSM back-end is not a solution for all problems, otherwise I would have written in stone that there is one backend and we'd be done. The MSM backend is a fully optimized machine, trying to pack as many features as possible at the lowest possible cost. There are however cases, where one would be ready to give up some features like state reuse and generic functors in exchange for reduced costs. For such cases, there is room for a mini-MSM backend (name from Barend Gehrels ;-) ). And in this case, your entry/exit solution appears a viable, interesting one for which I am thankful. When preparing the review, I had several possibilities: - make the current MSM backend, with lots of features, thus proving that the approach of the MPL book was a great one. - make a reduced, smaller cost version, with the certainty of being criticized for not having enough features (see review from FSM) and rending a disservice to the book. - make a 3rd one, more dynamic, which I want to do since a while. - make no review until all possible back-ends are done and make everybody wait at least one more year. Do we agree that solution 1 seems the more logical? I hope we managed to find a common ground and that a fruitful discussion can take place. Christophe
I'm out of time (not just the review period but other time constraints) for doing a proper review, something I regret. However I would like to vote for the acceptance of the msm backend conditional on: Improvements to documentation to formally and fully describe the msm interface. Inclusion of straight-forward out of the box configurability to support large FSMs. Note that this is a vote for the back end (and the basic front Row<> front end or a refinement of it only. I don't believe that euml, promising as it is, should be accepted yet - but see discussion in reply to Christophe below. - What is your evaluation of the design? The design is very well thought out overall. It seems (with a few exceptions the author has expressed an intention to address) to be capable of modeling all UML statechart concepts that I have used at least. Being able to do so with a highly performant and scaleable fsm "kernel" makes this library stand out from alternatives that are able to offer either high performance or expressive power but not both. - What is your evaluation of the implementation? I only briefly examined it. It is very clear and concise. I did not delve into the euml implementation. - What is your evaluation of the documentation? It provides an adequate introduction, although this is made more confusing than necessary due to the presentation of multiple interfaces etc. The documentation as it stands is adequate for a review by being expository of the library features and general concepts, but is inadequate for a finished library. In particular, a precise reference for the library interface would be very helpful and in my opinion a necessity for acceptance. - What is your evaluation of the potential usefulness of the library? I have found it to be usable for a realistically sized fsm (not using euml). I am not 100% happy with some aspects of the interface (see reply below) but it is adequate. Yes, with gcc 4.2.4 - Did you have any problems? I couldn't get the euml examples to compile. I'm not sure whether this is an environment problem (I was using boost 1.40 on Debian testing) or something else. I didn't spend much time investigating. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An unevenly in depth study. A quick look at the code. A few small experiments. Played with the tutorials. Started implementing a (sketch of) the itu Q.921 lapd protocol directly from the lapd state transition tables in Q.921 as an experiment. Tried to sketch out enough of the semantics as well as the states and transitions to be realistic. Only covered a fraction of this but enough to convince me that the library is adequately scalable for realistic problems. I would have like to spend more time investigating how best to use the library but has been a frantic time of year for me. - Are you knowledgeable about the problem domain? Reasonably. I've written fsms of varying complexity in a number of languages in a number of problem domains, written simple fsm libraries, and designed them in hardware. The rest of this message covers some areas where I thing the genericity of the library could be improved. However, I don't consider any of this well developed enough to make acceptance conditional on anything in it. On Tue, 2009-12-08 at 11:59 +0100, Christophe Henry wrote:
Hi Darryl,
I don't mind criticism, any of it, justified or not, as long as it doesn't stay vague and instead goes to concrete, argumented points. Vague negative comments bring little to the review and contribute to giving an incomfortable feeling to all participants.
I'm sorry my comments came across as negative. I only hoped to discuss some (admittedly vague) ideas for refinement, not criticise. My comments have been almost entirely around the back end and the more direct front-ends to it. I personally think euml should be a separate submission/review, once it is more "review ready". There seem to be boost version and compiler version issues in getting even the examples to compile. These are quite possibly outside of msm/euml itselfs control, but if nothing else, they prevent easy review of euml. I'm actually struggling with the above, because I think having euml in trunk, with tests being run, could facilitate resolving some of these issues. Maybe euml could be included as some experimental/example part of msm initially? The rest of my comments relate to the back end and the simpler fron ends. In general I like the proposed back end. My only "criticism" of it is that it could perhaps be refined to contain only the bare minimum necessary to express UML state machine concepts at the transition table level, and to provide very abstract interfaces to extend it. Then this back end kernel could be used to construct many styles of elaborated FSM. This is the only thing behind my attempts to do away with state objects containing entry/exit actions. Its just an idea, that I haven't had time to develop further. There is nothing I outright can't do with the existing design (except for the lack of in-state transitions, which has already been raised and, iirc, you have offered to address).
Constructive remarks are, on the other side, highly welcome! That's reason #1 for a review. I sometimes, like yesterday, take part in several parallel discussions, so I have little time left for remarks I cannot start anything with. Sorry about it, it's the negative side of the review. I'd be thankful if potentially useful but vague ideas were kept for a more quiet time.
I don't generally bombard innocent bystanders with my vague ideas. I took asking for a review to be asking for it :-)
I genuinely don't see why msm needs to instantiate state objects it owns at all.
If this is the point, then it is a solvable problem. Clearly, it doesn't strictly need. It's just a feature, which is in some contexts very useful. The main one is to be able to save some data in the states. This data can then be generically accessed by the generic functors, thus increasing reuse and encouraging clean code.
I understand thats the idea. But I find, in the case of writing code based on a protocol fsm, that the objects that implement the protocol don't really reflect the state directly (at least not all the time). They have rolse fairly orthogonal to the state.
The functor front-end will be your friend in this case. The same with eUML, but it doesn't have to be eUML.
In putting together the LAPD implementation I'm using the functor front end, but end up creating functors via a few macros that dispatch to the objects that do the work. I find they don't need access to anything other than the fsm (to post events back to) and the event (to access/process anything it contains). I'm fairly happy with that aspect of the interface. I haven't tried to do it yet, but it struck me that I could potentially use the state types alone (not the object ref parameters) as tags to determine which object to dispatch to. If I chose to have objects that were 1:1 with states I could - but it wouldn't be part of the fsm kernel. Is that concrete enough to make sense?
The second reason would be entry/exit:
I suggest spelling them enter<state>(machine) and exit<state>(machine) or machine.enter<state>() and machine.exit<state>().
Of course, this would be a solution. It's actually an interesting one, and if you don't mind, we'll keep for later (see below). Do we agree that it makes the machine slightly less readable?
No, I don't agree at all. I can't see how you can argue that having transitions specified in states as statechart does is less clear than a separate transition table, then claim that having enty/exit actions specified in states is more clear than having them similarly separated.
The 3rd reason is state reuse. This brings us to:
What does reuse of a state in msm mean?
Interesting question, which is sadly ignored by many fsm frameworks. A case would be when you want to avoid doing the same case again and again. You could then define a state hierarchy, even (gulps) OO-like for this (or better some template policy magic). For example, I personally often add some logging in debug mode, so that I know what happened in my system. The visitor is another good example of it. I hope that after having a look at it, you'll see the interest you can gain from it.
I personally find this response vague. Though you do propose something concrete below. The visitor is clearly unnecessary if there is nothing to visit. However msm should provide a way to "visit" the state types rather than values. I think we are really arguing about whether the type-value mapping should be in the back end or not. I claim not.
You might have easily missed another case in the doc. If you have a look at iPodSearch and iPodSearchEuml, you'll see where I want to go next. To states which implement STL algorithms. You will then be able to write complex algorithms by simply moving some predefined states on a diagram. I plan to call it the STL (State Template Library ;-) ).
It is very hard to comment on this because I haven't seen the CASE tool you propose and the description above and the examples isn't enough for me to understand its scope and capabilities. It sounds really interesting but I can't tell if I would find it compelling or not. And compelling or not, I don't see that it would help with some problem domains, such as the protocol implementation case I've been playing with, but perhaps I'm not understanding your modeling tool proposal's scope and metamodel. It isn't apparent to me that I am proposing anything that prevents the tool you describe being implemented on the modified back-end.
While this is for the future, I'll need independent, reusable states for it.
But why do they need to be part of the transition table based "kernel"? Don't pay for what you don't need/use?
No. For the record, in my opinion, the single the worst feature of statechart is the necessity to use custom reactions to implement some fsm <constructs. This was a subject of much discussion during the Statechart (FSM) review iirc.
I see. Then I probably misunderstood your point.
Yes. Rather. Sorry for the combination of complex grammar and outright incorrect grammar that would seem to have lead to this.
Can you perhaps explain why flags are needed?
Sure. If you look at the statechart doc, you'll see some state_cast. I personally find it not beautiful in my code. It's also hard to maintain when your fsm structure changes. Flags are faster, require no rtti, are more model-oriented as states define themselves their "property" and makes user code easier/smaller to read. It's even supported by eUML for better model-orientation.
Ok. I understand the problem with the RTTI based approach. But once again, I'm keen to take everything possible out of the states. I would rather see a separate declaration of a set of states used to define a "metastate" (a state analog with no in or out edges that is implicitly entered when any of the states it "contains" is entered).
I wanted to handle the entry/exit discussion separately. Hopefully I managed to convince you why states are useful and their instanciation brings some advantages.
I'm not outright against state instantiation. I can't be. I do really like statechart's state instantiation model. However, in the review of that library I did ask if there was any way that the costs associated with it could be avoided when not strictly needed (when the state contains no state-local storage). I'm asking a very similar question here, but somewhat more emphatically because this is the Msm (first M is important!) and it should surely be able to do this. Also, I think that by avoiding state instantiation in the core of the back-end, it should be easier to extend with *different* object instantiation models. I would really like to see msm provide a back end with a good set of interfaces to allow different state machine models to be implemented, all benefiting from having at their core a highly performant library.
Of course, there is a price to pay, though a small one (if without data, 1 byte/state). This is in most cases not a huge cost.
I agree there are cases where the price is still too expensive. I also agree, that the one current MSM back-end is not a solution for all problems, otherwise I would have written in stone that there is one backend and we'd be done. The MSM backend is a fully optimized machine, trying to pack as many features as possible at the lowest possible cost. There are however cases, where one would be ready to give up some features like state reuse and generic functors in exchange for reduced costs. For such cases, there is room for a mini-MSM backend (name from Barend Gehrels ;-) ). And in this case, your entry/exit solution appears a viable, interesting one for which I am thankful.
Ok. I'm just keen to see reuse of a common kernel, and separation of what seem to me to be largely orthogonal domains. That may not be practical. I am not a metaprogramming expert (nor a complete neophyte) and haven't been able to spend much time on this very interesting library, so I am quite possibly missing some very good implementation reasons for not taking such an approach.
When preparing the review, I had several possibilities: - make the current MSM backend, with lots of features, thus proving that the approach of the MPL book was a great one. - make a reduced, smaller cost version, with the certainty of being criticized for not having enough features (see review from FSM) and rending a disservice to the book.
Personally, my criticism of (that) FSM was around an unconventional and rigid fsm model. I could easily accept a library providing only a simpler model on which more elaborate models/concepts can be built. I hope msm can be that. aside - it is very confusing that Statechart pre-review as called FSM as well...
- make a 3rd one, more dynamic, which I want to do since a while. - make no review until all possible back-ends are done and make everybody wait at least one more year.
Do we agree that solution 1 seems the more logical?
Logical from what perspective? Buying votes or producing a good library? Politics... ;-) Darryl.
participants (2)
-
Christophe Henry -
Darryl Green