On Dec 12, 2012, at 11:40 AM, John J Barton wrote: > > > > On Wed, Dec 12, 2012 at 11:20 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> > 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 <al...@wirfs-brock.com> >> 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 <al...@wirfs-brock.com> >>> 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.
The effect of upon the target object will be the same. The exception thrown (in the absence of the use of Proxies) will always be a TypeError. The only variations is which property might me named in the implementation dependent text that might be attached to such TypeErrors. > > > 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. Basically, that is the same argument. Except that the property errors are specified. It is the order that is unspecified. > > 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/ Arguably, the operation didn't "die" at all. Instead it made a best effort to do everything that was requested that could possibly be done. I'll leave it to MarkM , if he wants to make more of a case. > > 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
