Re: several messages about binding stuff

On Thu, 28 Jun 2007, Cameron McCormack wrote:
> > 
> > Regarding the 3.2.2 ed note, I vote for giving a mandated way; 
> > otherwise when people rely on a particular chain, it'll break in 
> > another browser and eventually all the browsers will have to do 
> > whatever IE picked (when they implement this).
> 
> The problem with mandating it is that no browser currently implements it 
> exactly as I’ve done in the example, AFAIK.  Given that you can’t 
> normally navigate the prototype chain from script anyway (well, Mozilla 
> seems to have .__proto__ properties to access [[Prototype]]), it’d be 
> sufficient to specify it with some lower level of detail, as Boris 
> suggested in the last para of 
> http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0022.html . I 
> haven’t really captured that yet with the single paragraph above the 
> example, but expanding it out a bit with some specific conditions that 
> have to hold about calling [[Get]]/[[Put]] on host objects and interface 
> prototype objects might be enough.

(This is now 4.2.2. Interface prototype object)

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


> > 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. :-)


> > 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?


> 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?

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


> > 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...


> > 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. :-)


> > 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.


> 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. If 
someone comes up with a usecase for it, we can revisit it. In fact, are 
there any JS-implementable objects that do more than one operation?

Be conservative. We can always expand. It's much harder to shrink.


> > Then again, it's actually a good reason for not making any interface 
> > implementable by Object in JS too... can we have another attribute to 
> > stop that too? :-)
> 
> What about other languages?

I don't really mind what you do for the other languages. :-)


> I like to keep those sort of options open, rather than preventing them.

If you prevent them now, you can add them later. If you add them now, you 
can't prevent them later. That's why I prefer starting with them 
prevented.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'