On Wed, Dec 12, 2012 at 11:20 AM, Allen Wirfs-Brock <[email protected]>wrote:
> > On Dec 12, 2012, at 10:52 AM, John J Barton wrote: > > > > > On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock <[email protected] > > wrote: > >> >> On Dec 12, 2012, at 10:23 AM, John J Barton wrote: >> >> >> >> >> On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock < >> [email protected]> wrote: >> >>> >>> On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote: >>> >>> All the Object functions that operate on multiple properties are >>> currently specified using *pendingException* which reports the first >>> thrown exception after going through all the properties. defineProperties, >>> freeze, etc. >>> >>> >>> In, ES6. This is a breaking (hopefully nothing) change from ES5 that >>> was suggested by Mark Miller. >>> >>> The desire is to decrease the non-determinism that an early throw >>> introduces. >>> >> >> How can multiple calls to Object.mixin with identical state result in >> different results? >> >> >> Because the order that the source properties are visited is unspecified. >> It can differ among implementations and in theory could even differ within >> a single implementation. >> >> >> >>> In the ES6 approach all property updates that can occur will occur, >>> before the exception is thrown instead of leaving the object in a less well >>> defined partially updated state. >>> >> >> If an exception is thrown because of an error in Object.mixin, what state >> is the object in? Will the spec define that state? >> >> >> Yes, all property additions (to the target object) that can complete >> will complete. >> > > And I assume then that the exception thrown will be 1) standardized, 2) > specify the properties that are undefined on the target as a result of > exceptions, and 3) provide those exceptions. That seems to be what we need > to have any chance to use this feature. > > > It is currently specified as a whatever exception is first thrown by an > operation upon an individual property. Those exceptions are specified at a > more primitive level. > So the results are not in fact the same across browsers. > > In general, the ES spec doesn't specify anything about thrown exception > other than which specific exception "class" to throw. It does not specify > a message or any other added payload. > > I'm not sure that there is an actual utilitarian use cause for this > behavior. > That is my objection to the late-exception definition: unless you know which properties failed and why, the mixin result is in an undefined state. The details of the state are not useful. > It is more about minimizing non-determinism that might impact > interoperability among implementations. > IMO your best argument would be: To insure interoperable implementations in the presence of unspecified property order and property errors. I think that argument is weak because all implementation should have the same outcome in the presence of errors: the result is not useful. Nevertheless, I can imaging a use for the interoperability in cross-browser test suites. > > How would throwing early versus throwing late make any different to you? > Because 1) late is a waste, the result is undefined anyway, 2) the exception thrown is a lie, the operation did not die on the property reported but continued and failed to die on an unreported number of subsequent properties/ But if you've already decided this, let's move on: we need Object.mixin more than we need one with any particular exception properties. jjb
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
