- 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
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 “valuetypes”. 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