Re: several messages about binding stuff

Hi Ian.

Cameron McCormack:
> > [explicit prototype chain stuff]

Ian Hickson:
> I understand what you're saying, but I'd still rather have any black box 
> behaviour be unambiguous. (Non-black-box behaviour is irrelevant.)

Acknowledged.

Ian Hickson:
> > > It would be nice if the spec could suggest some boilerplate text for 
> > > other specs to include, in the way that RFC2119 does. For example:
> > > 
> > >    IDL sections in this specification must be interpreted and implemented 
> > >    as required by the "Language Bindings for DOM Specifications" 
> > >    specification. [DOMBIND]
> > 
> > Good idea.  I’ll put something like that in the conformance section 
> > when I get to it.
> 
> Prod. :-)

That has been added already, but in the “Referencing this specification”
section.

> > > Is there anything else that a spec would have to do other than say 
> > > something like the above and then use the various features you define? 
> > > e.g. is there ever a case where prose is necessary to fully define 
> > > something?
> > 
> > There are some cases that aren’t covered by the spec currently, like 
> > the Image/Option/etc. constructor functions from HTML 5.  I haven’t 
> > gone through HTML 5 in detail yet to check if I’ve missed anything 
> > else.
> 
> It would be nice to define this. Can it be defined by just having a 
> [[Constructor]] property that specifies a particular name?

Like this?

  [Constructor=Image]
  interface HTMLImageElement : …

which would cause HTMLImageElement not to have [[Construct]] on
HTMLImageElement, but for Image to exist with [[Construct]] and nothing
else?

Do these special constructors have any functionality other than
[[Construct]]?

> > But you could imagine a spec requiring a [[Get]] method that does 
> > something in particular, which wouldn’t really be worth putting in the 
> > Bindings spec because it’s too specific.
> 
> How do you mean?

I mean, perhaps some special [[Get]] behaviour would be wanted on some
object that is not common enough to warrant special syntax in the IDL.

> Also, is the "location" object and setter covered by this spec?

I believe so, something like this:

  [Stringifies=href]
  interface Location {
             attribute DOMString href;
    void assign(in DOMString url);
    void replace(in DOMString url);
    void reload();
  
    // URI decomposition attributes 
             attribute DOMString protocol;
             attribute DOMString host;
             attribute DOMString hostname;
             attribute DOMString port;
             attribute DOMString pathname;
             attribute DOMString search;
             attribute DOMString hash;
  };

  interface HTMLDocument : … {
    …
    [PutForwards=href] readonly attribute Location location;
    …
  };

  interface Window : … {
    …
    [PutForwards=href] readonly attribute Location location;
    …
  };

But the assignment to href resulting in calling assign() isn’t handled
by anything in the IDL.  Something like [PutCalls=assign] could be added
if needed, I guess.

> > > Is it necessary to explicitly list the exceptions that a method, 
> > > getter, or setter can raise?
> > 
> > Good question.  OMG IDL says:
> > 
> >   The absence of a raises expression on an operation implies that there
> >   are no operation-specific exceptions. Invocations of such an operation
> >   are still liable to receive one of the standard system exceptions.
> > 
> > ECMAScript 3rd ed doesn’t have any declarations for exceptions.  Java 
> > does, but you need only list checked exceptions (and the Java bindings 
> > for DOM Core inherit from RuntimeExeption).
> > 
> > Given that the IDL is meant to be language neutral though, and there are 
> > some languages where all exceptions thrown must be declared, it makes 
> > sense to require it.  (It is somewhat informative, anyway.)
> 
> Well, we're only ever going to be raising DOM Exceptions, right? I don't 
> want to have to put "raises DOMException" on every line of every IDL 
> block...

Only for the ones that would throw it though, right?  But as it stands,
the spec would allow you to omit the raises clause but still raise a
DOMException.

> > > What's the purpose of the 'module' block?
> > 
> > It’s used to group declarations together, much like namespaces in C++. 
> > In Java bindings for DOM specs, the names of the modules correspond to 
> > package names.  In the ES binding defined here, they aren’t used.
> 
> So do I have to mention them in the HTML5 spec? If not, I'd ideally like 
> to just drop it from this spec too. :-)

I think it’d be fine not to include it in the in-line snippets that
define the interface described in that section, but I think you should
include them in an html5.idl that contains all of the IDL.  (You’d only
need one ‘module html { … }’ then.)

> > > Is the idea that DOM Core will define an 'exception' block for 
> > > DOMExceptions?
> > 
> > Yes, and it does already:
> > 
> >   http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-17189187
> > 
> > Or do you mean for the constants?  The issue I have in the document at 
> > the moment is for associating constants with exceptions.  In that DOM 3 
> > Core section, the ExceptionCode constants are just declared at the 
> > module scope, but in the ES binding the constants are on the 
> > DOMException interface object, and in the Java binding they’re on the 
> > DOMException class.
> 
> Right, I meant for exceptions. Right now DOM Core is rather vague on this 
> front.

I think the two language binding appendices of DOM 3 Core are clear
about where thoes particular exception code constants should live.

> > OK so this brings up a point.  Currently the document states that an ES
> > native object can implement an interface by having a host object with
> > properties (whose values are functions) for each operation on the
> > interface.  So if the interface had constants on it, these would not
> > need to be put on the native object:
> > 
> >   // -- IDL --
> >   interface B {
> >     const int x = 1;
> >     void f();
> >     void g();
> >   };
> > 
> >   // -- ECMAScript --
> >   var b {
> >     f: function() { },
> >     g: function() { }
> >   };
> > 
> > First, is it a good idea to allow this?  I don’t want to discriminate 
> > against being able to implement interfaces in ES just because there are 
> > constants defined on the interface, necessarily.  It does mean though 
> > that you wouldn’t be able to refer to the constant of a native object 
> > implementing B, but you would of a host object implementing B.  I 
> > don’t know if I like this discrepancy.
> 
> I would just say that JS-implementable interfaces can't have constants.

That’s probably a reasonable thing to start off with.

> If someone comes up with a usecase for it, we can revisit it.

OK.

> In fact, are there any JS-implementable objects that do more than one
> operation?

That I don’t know.  There aren’t really any issues with a native object
implementing an interface that has multiple operations, so I think it’s
safe to leave it at that.

-- 
Cameron McCormack, http://mcc.id.au/
 xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

Received on Monday, 31 March 2008 03:56:44 UTC