From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-22 16:33:54
Rob Stewart wrote:
[snip]
> Without digging out the previous messages and confirming the
> matter, I think Jonathan's suggestion, quoted above, was simply
> that *when* the user wants separate translation units *and* the
> features that would typically require tight coupling, you could
> introduce a weaker link -- some form of indirection -- that would
> slow the resulting FSM or even complicate its specification, but
> would at least permit the functionality.
I think that's close to what I understood...
[snip]
> This is right on target. *Since* the current design, with all of
> its requirements is so much slower, then the onus is on Andreas
> to explain why the requirements his library meets exceed those
> met by other FSM libraries and directly lead to the performance
> overhead. Clear distinctions regarding the performance
> improvements gained by avoiding the performance draining features
> in an FSM while still using this library will help to demonstrate
> that situation, too.
[and]
[snip]
>> Normally, in designing a framework one considers a small handful
>> (say two to six) of alternate designs which view the subject matter
>> from completely different perspectives. In your case, what were
>> those alternate designs?
>
> Note that Jonathan is asking that those alternatives be
> documented. That way, other developers who wonder why you didn't
> try X will see that you did and they'll see why you decided it
> was not appropriate.
I have agreed to add such documentation in one of my previous answers.
>> Let me make one last attempt to explain what should be in the
>> rationale. Look at section 16.2 of "The C++ Programming Language",
>> 3d ed. Here Stroustrup gives two design criteria for a containers
>> library, and then discusses three designs:
>>
>> "Specialized containers and iterators" - satisfies the first
>> criterion "Based Containers" - satisfies the second criterion
>> "STL" - satifies both criteria
>>
>> I'm not suggesting that you give such a detailed treatement as
>> Stroustrup. However, if you were to give a similar overview of the
>> landscape of possible FSM frameworks, and thoughtfully discuss the
>> tradeoffs in flexibility and performace which each involves,
>> reviewers might have some confidence that you are aware of the
>> techniques which might be used to construct a fast, flexible FSM
>> framework, and have carefully considered the design.
>>
>> This type of overview would probably be a useful component of any
>> library's documentation; in your case it is made absolutely
>> essential by the performance figures you cite.
>
> I don't think I can add any more to that. I think it is
> reasonable and clear.
It is but I'm not sure how this is relevant (I already agreed to add
such documentation).
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.