W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 2 Jul 2009 11:20:57 +1000
To: Maciej Stachowiak <mjs@apple.com>, Marcin Hanclik <Marcin.Hanclik@access-company.com>, "Kruessel, Steffen" <Steffen.Kruessel@fokus.fraunhofer.de>
Cc: Giovanni Campagna <scampa.giovanni@gmail.com>, WebApps WG <public-webapps@w3.org>, ian@hixie.ch
Message-ID: <20090702012056.GA21736@arc.mcc.id.au>
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
> http://dev.w3.org/2006/webapi/WebIDL/#Callback 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 ≝ http://mcc.id.au/
Received on Thursday, 2 July 2009 01:22:06 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:17 UTC