While thinking about this case, think about the case of an operator that takes two inputs through two different 1 to 1 connections, hence they are all in the same node and there will not be a network connector between them?
I am not sure how this works at the moment but I think that we need to consider these cases. ~Abdullah. Amoudi, Abdullah. On Wed, Dec 9, 2015 at 10:56 AM, abdullah alamoudi <[email protected]> wrote: > There seems to be something missing here which is the legal function calls > that can be made in each state. For example: > > 1. Is it legal to call open() on an open instance of IFrameWriter? If not, > then is it the responsibility of the IFrameWriter to throw an exception in > that case > ? > 2. Is it legal to call close() on a closed instance of IFrameWriter? If > not, then again, who's responsibility is it to throw an exception in that > case? > 3. Is it legal to call fail() on a failed instance of IFrameWriter? If > not, then again, who's responsibility is it to throw an exception in that > case? > > I am asking this because I think that is happening in some places in the > code already. > Should we allow that? > > Abdullah. > > Amoudi, Abdullah. > > On Tue, Dec 8, 2015 at 11:56 PM, Mike Carey <[email protected]> wrote: > >> +1 >> >> On 12/8/15 5:43 PM, Till Westmann wrote: >> >>> Hi, >>> >>> When improving test coverage we noticed, that there are some >>> inconsistencies wrt. state management and transitions in different >>> implementations of IFramewriter. These inconsistencies cause a number of >>> test failures - especially when testing error conditions. Ian has written >>> up a document [1] on the current contract (which is unfortunately not >>> consistently implemented) and on an alternate contract that we have >>> discussed. >>> We currently believe that the alternate contract would be preferable as >>> there is more similarity in the approach to handling errors during open() >>> or nextFrame(). >>> Our proposal is to >>> 1) Adopt the alternate contract and document it in >>> a) the IFramewriter javadoc and >>> b) a design document. >>> 2) Implement new operators according to the alternate contract. >>> 3) Add mock-based unit tests (e.g. using Mockito [2]) for new operators >>> that verify that the contract is maintained. >>> 4) Add mock-based using test for existing operators as bugs are found >>> and fixed. >>> >>> Please take a look at the document and tell us, what you think about the >>> contract and the approach. >>> >>> Thanks, >>> Abdullah, Ian, Yingyi, and Till >>> >>> [1] >>> https://docs.google.com/document/d/1QJ8X7QFMMax5D5k9RVje6hoNr_SNZSW9Oshzv7DpcQw/edit?usp=sharing >>> [2] http://mockito.org/ >>> >> >> >
