Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject

Maciej Stachowiak:
> The name NativeObject seems nondescriptive and could easily be taken as 
> the opposite of what it means. For example, in the browser context, code 
> written in C++ is often called "native" but code written in JavaScript 
> typically is not.

I can buy this confusion (although “native object” is the term used by
ES-262 for non-host objects).

> I'm not sure if there is a better word than "Callback" to connote an  
> interface that is expected to be implemented by clients of the API  
> rather than implementation of the API. Maybe "ClientInterface" or  
> "ClientObject".

Some specs, like DOM 3 XPath, have interfaces that can be implemented by
script or by the UA.  I think we want a name that suggests that user
code can implement the interface, not necessarily that it’s always the
case that such objects are implemented by user code.

Marcin Hanclik:
> What about [ESNativeObject]?

Maciej Stachowiak:
> I don't think the property should be ES-specific. It would probably have 
> effects for other language bindings too. I'm also not sure this  
> clarifies the use of Native.

Although I have moved [Callback] to the “ECMAScript-specific extended
attributes” section, if it gets named more generically (and has a more
generic meaning, such as “intended to be implemented by user code”) then
I’ll move it back.

Marcin Hanclik:
> Taking the multi-language requirement, I think we mean an interface
> that is sandboxed within some VM, be it Java, JS or whatever else and
> that is not exposed outside of the VM apart from being a parameter or
> result of the operation.
> [ClientXXX] naming could result in associations with client-server
> architecture and it seems not to be our case?
> What then about [InternalInterface]?

I don’t think “internal” is the right word for it.  I think as with
[NativeObject], “internal” could be interpreted as being an interface
that is just used internally by the implementation.

Kruessel, Steffen:
> If the extended attribute should not be ECMAScript, the description at
> must also be revised due
> to the strong ES-reference.
> What about [ValueTypeInterface]?

I think that has the potentional to be confused with the concept of

Sorry, I didn’t meant to open up a big naming discussion.  I’m going to
leave it as [Callback] for now, move it to the non-ECMAScript specific
section and add some wording making it clear that it’s not just for
interfaces with operations.

Cameron McCormack ≝

Received on Thursday, 2 July 2009 01:22:06 UTC