Object.define ==> Object.mixin??

John J Barton johnjbarton at johnjbarton.com
Wed Dec 12 11:40:58 PST 2012


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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/45454b72/attachment-0001.html>


More information about the es-discuss mailing list