[Bug 12248] Make objects first-class API citizens

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

--- Comment #27 from Cameron McCormack <cam@mcc.id.au> 2011-03-08 22:18:42 UTC ---
(In reply to comment #21)
> How can you write a generalized serializer when only certain keyword parameters
> specific to the method being specified, are wanted?
> 
> You can abstract a helper that looks for a list of keys, and returns a list of
> values, say. But the processing for a given method-being-spec'ed will not first
> blindly clone (by serialization) the object passed as keyword-parameter set.

I was thinking more of the structured clone use case (where you would serialize
everything), and then extending it to work for this keyword parameter use case.

> > 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...)).
> 
> Why? Can you show any DOM or WebAPI/Apps methods being proposed or already
> spec'ed that use such a "deep" keyword-parameter-set object?

For the keyword parameter use case, no.

> What problem is being solved here? I thought the issue was how to spec a method
> M called like so (say on a DOM node N):
> 
>   N.M(arg1, arg2, {key1:val1,  ... keyN:valN});

I didn't realise that was all we were trying to solve.

Some specs (such as ones from the DAP WG) are currently allowing keyword
parameter objects like this just by defining an interface:

  interface N {
    void M(in long arg1, in long arg2, in KeywordParams kwparams);
  };

  interface KeywordParams {
    attribute long key1;
    attribute DOMString key2;
    attribute object key3;
    ...
  };

So to do what comment 26 suggests, we can add some steps in here:

  http://dev.w3.org/2006/webapi/WebIDL/#es-interface

under step 4, which would do a [[Get]] for each property that corresponds to an
IDL attribute in the order that they appear in the IDL.  We'd also need to
state that whenever the implementation is getting the value of the IDL
attribute of such an object, it uses the value that was [[Got]] up front.

We could consider introducing new syntax for keyword parameters, instead of
forcing it through an interface.  That might be better, as (in theory) bindings
for languages that have native support for named parameters would be nicer.

(In reply to comment #24)
> 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.

OK.  Is it worth having an IDL type that means "the kinds of values you can get
out of the structured clone algorithm"?  ("StructuredData"?)  That makes sense
to me for plain objects, arrays and primitives, but the structured clone
algorithm deals with various other types too: Date, RegExp, ImageData, File,
Blob, and FileList.

-- 
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 22:18:47 UTC