Re: [heycam/webidl] Update attribute setter/getters in various ways (#217)

bzbarsky commented on this pull request.



> +                    then:
+                    1.  If |attribute| was specified with the [{{LenientThis}}]
+                        [=extended attribute=], then return <emu-val>undefined</emu-val>.
+                    1. Otherwise, <a lt="es throw">throw a <emu-val>TypeError</emu-val></a>.
+            1.  Let |R| be the result of performing the actions listed in the
+                description of |attribute| that occur on getting (or those listed in the description
+                of the inherited attribute, if this attribute is declared to
+                [=inherit its getter=]), on |O| if |O| is not <emu-val>null</emu-val>.
+            1.  Return the result of [=converted to an ECMAScript value|converting=] |R| to an
+                ECMAScript value of the type |attribute| is declared as.
+
+        And then, if an exception was thrown:
+
+        1.  If |attribute|'s type is a [=promise type=], then:
+            1.  Let |reject| be the initial value of [=%Promise%=].reject.
+            1.  Return the result of calling |reject| with [=%Promise%=] as the

> I really don't think it's that weird. It's about the exception case.

The problem is that unlike sync functions, which have a return value and a possible exception which are exposed to the caller in different ways, Promise-returning functions use a return value to represent both things.  This makes [SameObject] a pretty confusing thing to start with: is it referring to the Promise object returned, or to its resolution value in the non-exception case, for example?  If we really reason by analogy to sync functions, it should be referring to the resolution value...  but in practice people and the spec use it to mean the actual Promise return value.  Which doesn't even have an explicit equivalent in the sync function case in JS; it would be a continuation in languages that have such things.  So any reasoning by analogy here is broken right now anyway.

It's worth taking a step back for a second and asking what the point of [SameObject] really is and why we have it at all, then trying to figure out what it means to map that concept to promise-returning getters.  Assuming that's really possible.

> WebKit: #186

Thank you.  And Edge?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/217