[Bug 12248] Make objects first-class API citizens

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

--- Comment #24 from Allen Wirfs-Brock <allen@wirfs-brock.com> 2011-03-08 05:55:26 UTC ---
comment #15:
> Some of the people in this discussion have as a high priority preserving JS
> semantics in all cases, so they think losing non-data properties on objects
> passed as a way of grouping some data is a worse deal than the possibility of
> underspecified behavior due to weird getters.  I'm not entirely sure I agree
> myself; I see the use of getters here as a definite edge case, and at that
> point the question becomes how much that edge case is worth catering to.  Is it
> worth the fact that behavior will have to be explicitly undefined in some cases
> (and that this set of cases may not even be describably adequately)? 
> 
> Maybe it is.  Maybe it's not.

On of the first hard lessons I learned when I started working in this areas was
that the web average developer does not make a distinction between JavaScript
objects/JavaScript libraries and DOM objects/Web APIs.  They are all just
JavaScript objects to the developer.  When DOM/Web App objects behave
differently from other JavaScript objects or lack JavaScript object
functionality or restrict normal use cases this just creates confusion for
developers and makes the entire browser platform harder to learn and use.

Also, as time goes on you are going to have more of these situations. What
about objects implemented via the JavaScript Proxy mechanism?  Will any Proxy
based object be forbidden in web APIs?

Also, all the issues that are being brought up here already occur and are dealt
with in the ECMAScript specification and JavaScript implementations.  Why would
they be tractable in JavaScript but intractable in other parts of the web
platform?

comment 14:
> Just so that I am clear on the two choices here:
> 
> (A) if serializing, you would end up calling every getter on the object (and on
> all of the objects referenced by its properties, and so on) in a particular
> order, before actually doing the work in the method


No, that's not how you do it, at least for the descriptor parameter case. You
don't just arbitrary get the value of every property.  A descriptor parameter
typically has a "syntax", properties that must or must not appear together, but
have specific types or ranges of values, etc.  You process these just like you
would process a syntax driven variable argument list (eg, printf). You process
it according to whatever rule you define for each particular situation. 

comment #18:
> The generalized version of ToPropertyDescriptor that would be used here would
> serialize the whole object graph starting from its argument.  (At least, that's
> how I imagined the serialization to work.)  That could well result in getting a
> property "whose value it [the method] does not use".
>
> ToPropertyDescriptor itself doesn't look at properties other than "enumerable",
> "configurable", etc.  My (A) would look at every property on the object (and
> its objects (and its objects...)).

I think you need to distinguish the special case of processing arguments
(especially descriptor arguments) to a specific API from the more general case
of serializing an arbitrary object structure for storage or communication
purposes.  The second case requires that you look at every property.  The first
does not and is just likely to get you in trouble if you access properties that
are explicitly used by the API.

Processing arguments is just part of specifying and implementing an API.  In
many cases the order in which the arguments and argument properties are
accessed could be arbitrary.  This is the case for some of the properties in
ToPropertyDescriptor. However, the specification chooses an explicit order and
interoperability requires that implementations follow that order.

One of the classic performance bugs in  dynamic object-oriented language based
applications is excessive and redundant argument validation. If every method
unnecessarily validates every argument, even ones that are just passed on to
subsequent calls then your performance will suck.

-- 
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 05:55:28 UTC