Excellent! +1! That captures my concern precisely. Thanks!
On Wed, Mar 18, 2009 at 12:31 PM, Allen Wirfs-Brock
<[email protected]> wrote:
>>-----Original Message-----
>>From: Mark S. Miller [mailto:[email protected]]
>>Sent: Wednesday, March 18, 2009 10:27 AM
> ...
>>See again the language I propose for sort. While leaving the choice of
>>sorting algorithm unspecified, I place bounds on the range of side
>>effects it may cause even under uncooperative conditions. If we really
>>wish to leave the precise algorithm unspecified for these others, the
>>same qualifying language could still be applied.
>>
>
> The only thing that I see in the language in your previous message that may
> not be already covered is "[if any of the [[Get]], [[Put]], or [[Delete]]
> operations fail,] the only side effects sort would cause would be that
> brought about by calling these other operations."
>
> Personally, I think this concept is already implicit in the sort algorithm
> and most other algorithms in the specification. However, I wouldn't mind
> making it explicit for the other array methods if we could also made it
> explicit that implementation may use alternative algorithms that apply
> [Get]], [[Put]], or [[Delete]] in possibly different orderings.
>
> Here is my first cut at a generic version of language that might accomplish
> that:
>
> The above algorithm is intended to describe the result produced by this
> function in the absence of any error conditions. It is not intended to imply
> the use of any specific implementation technique. The above algorithm
> produces its results by using a specific sequence of calls to internal
> methods and abstract operations. Implementation may use other algorithms
> that use a different sequencing of these calls as long as an identical
> results is obtained in the absence of errors conditions. If any internal
> method call invokes a get or set function of an accessor property that has
> side-effects or if an error occurs the observable side-effects of this
> function are implementation defined but are restricted to those that would be
> produced by some sequence of the internal method and abstract operation calls
> in the above algorithm.
>
> Allen
>
--
Cheers,
--MarkM
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
