RE: Interpretation Algorithm calls some() on an OrderedSet

The standard logical definition would say that some() would return false on an empty set, but every() would return true.

- Jim

-----Original Message-----
From: Gavin Kistner [mailto:phrogz@me.com] 
Sent: Friday, June 27, 2014 11:06 PM
To: Jim Barnett
Cc: www-voice@w3.org
Subject: Re: Interpretation Algorithm calls some() on an OrderedSet

Also: should some() return true or false for an empty set/list? How about every()?
(Perhaps there's no case in the algorithm where it matters?)

On Jun 27, 2014, at 9:00 PM, Gavin Kistner <phrogz@me.com> wrote:

> Similarly getTransitionDomain() calls every() on an OrderedSet, which is also only defined for List.
> 
> On Jun 25, 2014, at 7:02 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:
> 
>> You're right.  I think I'll add some to OrderedSet since its definition will be straighforward.
>> 
>> - Jim
>> On 6/24/2014 5:21 PM, Gavin Kistner wrote:
>>> Trace of a particular code path in the algorithm causes an OrderedSet() to have some() called on it, but this method is not defined for OrderedSet.
>>> 
>>> enterStates():
>>>   statesToEnter = new OrderedSet()
>>>   ...
>>>   computeEntrySet(...,statesToEnter,...)
>>> 
>>> computeEntrySet(...,statesToEnter,...):
>>>   ...
>>>   addDescendantStatesToEnter(...,statesToEnter,...)
>>> 
>>> addDescendantStatesToEnter(state,statesToEnter,statesForDefaultEntry):
>>>   ...
>>>   if not statesToEnter.some(...)
>>> 
>>> 
>>> Either some() needs to be defined for OrderedSet, or the line above needs to become:
>>>    if not statesToEnter.toList().some(...)
>>> 
>>> 
>>> The same problem exists in addAncestorStatesToEnter()
>>> 
>>> (After getting quite far in the tests with LXSC I failed the 3rd preemption test, and decided to rewrite the core interpreter to match the latest spec algorithm in a very direct manner.)
>> 
>> -- 
>> Jim Barnett
>> Genesys
>> 
> 
>

Received on Saturday, 28 June 2014 12:32:17 UTC