[Bug 12248] Make objects first-class API citizens

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248

--- Comment #9 from Brendan Eich <brendan@mozilla.org> 2011-03-08 02:55:48 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > Storing into IndexDB is clearing such a boundary.  But I don't think it would
> > be reasonable to say that every call from a script into a web API crosses such
> > a boundary. That would seem to require that essentially all interface
> > specification have to give some consideration to these issues.  They
> > individually need to either be identified as a serialization boundary that
> > explicitly ensures that the serialization takes place or they will have to
> > explicitly deal with the possibility of accessor side-effects.  You simply
> > can't pretend that these issues don't exist.
> 
> What use cases do we have for that boundary not existing?

ES5 and a bunch of JS libraries use objects as keyword parameter sets, with no
serialization. You can define getters on the keyword parameter objects and they
will be called, "in process", with whatever effects you contrive. This is part
of JavaScript.

> Is it unreasonable
> for all instances where UAs inspect JS objects passed to them to be able to
> handle exceptions, side effects and resource exhaustion?

Yes.

JS engines have to handle runaway recursion, iloops, and OOM. This is currently
not normatively specified with quotas or lower bounds. It is left to the market
to deal with as a quality of implementation issue. That is not "ideal" but it
is not a high priority to "fix" with more (and more complex) spec machinery.

> If we can get away with always serializing so that we can deal with access
> side-effects up front, and not have to ignore accessor properties, I'd like to
> do that.

Why not do what ES5 and all the JS libraries already do, and avoid unnatural
(to JS) getter-free serialization semantics?

/be

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 8 March 2011 02:55:50 UTC