Re: [heycam/webidl] Replace serializers by toJSON and [Default] extended attribute (#323)

Finally adressing @domenic's comments here. Sorry for the delay in getting back to this.

> I guess the two big outstanding questions to me are:
>
> 1. Whether we want the generic-ness of [Default] and default operations

The reason behind this was that (1) it turned out to be trivial to generalize, (2) it was more aesthetically pleasing to write: `[Default] any toJSON();` than `[DefaultToJSON] any toJSON();`, and (3) it was more extensible, thus future proof. I didn't really see an issues with the generalized version besides a false promise that it could be used for other operations and a slightly higher cognitive load when reading the spec.

That said, I'm not attached to it at all and I'm happy to go with whatever people prefer. 

> 2. Whether we want the default algorithm to perform all these observable-from-ES steps, or go straight to the backing stuff

I don't have a strong opinion here outside of saying that it is really hard to spec the ES route. As discussed above, ES Get relies on the prototype chain and, apparently, that's not what makes sense from an implementation perspective. We'd need to spec dedicated Get operations here that would call the getters defined higher up in the prototype chain. This means we'll need to track how ES Get is specified and edit our own version accordingly. I'd rather avoid that.

The whole situation feels somewhat of a code smell. While the [Default] toJSON operation certainly makes sense in C++, it feels awkward in JS, where you'd probably implement that dynamically. If we're nonetheless sure this is the right algorithm to spec, we should probably got straight to the backing stuff and replace that with slots once we have those spec'ed.


-- 
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/323#issuecomment-287844699