Object.define ==> Object.mixin??

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Dec 12 11:20:06 PST 2012


On Dec 12, 2012, at 10:52 AM, John J Barton wrote:

> 
> 
> 
> On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock <allen at 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 <allen at 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.

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.  It is more about minimizing non-determinism that might impact interoperability among implementations.

How would throwing early versus throwing late make any different to you?

Allen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/62a31770/attachment.html>


More information about the es-discuss mailing list