RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject

What about [ESNativeObject]?

Regarding the whole use case (PositionOptions and its usage in Geo spec, similar use cases in many BONDI modules) that ignited this mail thread, in BONDI we consider the proposal of [Enumerable] extended attribute for interfaces (suggested off-line by Cameron) and [Optional] for attributes. In short we talk about the case that would resemble "passing arguments by value", that would allow incomplete specification of the object properties -  both as input/argument/value and as output/object and that is about property enumeration (i.e. about removal of {DontEnum} that is a standard now for Web IDL interface properties).
There will be another email about that posted soon.

BTW:
Property enumeration seems to be a topic also in this mail thread:
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1371.html

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Wednesday, July 01, 2009 6:11 AM
To: Cameron McCormack
Cc: Giovanni Campagna; Kruessel, Steffen; Marcin Hanclik; WebApps WG; ian@hixie.ch
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject


On Jun 30, 2009, at 8:12 PM, Cameron McCormack wrote:

> Hi Steffen, Giovanni.
>
> Giovanni Campagna:
>> [Callback], despite the names, does not mean that the interface will
>> be called back by a method accepting it (although that was the
>> initial
>> use case). It barely means that you can convert an Object (in the
>> ECMAScript sense) to an object in the WebIDL sense, of that
>> interface.
>
> I agree with everything Giovanni said.
>
> Regarding the name of the extended attribute: it used to be called
> [NativeObject], but there were restrictions on it so that it could
> only
> be used on interfaces with operations (and not attributes).  Ian then
> requested it be renamed to [Callback], since that was more
> descriptive.
> Since that restriction has now been lifted, and [Callback] interfaces
> can have attributes, I agree that [Callback] isn't the most obvious
> name
> any more.
>
> Anybody object to renaming it back to [NativeObject] then (or can
> suggest a better name)?

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. But "NativeObject" would be applied to
interfaces that are expected to be implemented in JavaScript, perhaps
even just by specifying a function directly.

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

Regards,
Maciej


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Wednesday, 1 July 2009 06:30:54 UTC