I think you're right. Cheers, Abdullah.
Amoudi, Abdullah. On Wed, Dec 9, 2015 at 11:48 AM, Till Westmann <[email protected]> wrote: > I think that the state diagram says that it’s not allowed. > However, I don’t think that each implementation should check that, as that > would require additional state and code in each operator that should not be > needed (if everybody sticks to the contract). > If we want to check that the contract is maintained we should do that > either in the unit tests or by introducing a wrapper that checks the > contract on top of the operator itself. This wrapper could then be added > during plan generation if indicated by a user (e.g. by setting a flag). > > My 2c, > Till > > On 9 Dec 2015, at 10:56, abdullah alamoudi 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/ >>>> >>>> >>> >>>
