RE: PositionOptions

Hi Cameron,

Thanks for the clarifications.

>>If you’re happy making requirements just for the ECMAScript language
>>binding of the Geolocation spec, then that will work.
Currently I consider only ECMAScript.
I do not want to break Java bindings, though.
Getters and setters are handled differently in ES and Java, ok.

So is my understanding correct that the following is the interface specification that would work in the use case we consider?
[Callback]
interface PositionOptions {
  attribute boolean enableHighAccuracy;
  attribute long timeout;
  attribute long maximumAge;
};

Documentation in Web IDL spec will definitely help.
I think the examples from this mail thread could be simply inserted into Web IDL spec for clarity.

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: Cameron McCormack [mailto:cam@mcc.id.au]
Sent: Thursday, June 18, 2009 2:32 AM
To: Marcin Hanclik
Cc: public-geolocation
Subject: Re: PositionOptions

Marcin Hanclik:
> > > then you’ll need to use [Callback] on the interface.
> > >
> > >  http://dev.w3.org/2006/webapi/WebIDL/#Callback

> It's a bit weird, but ok.

The reasoning is that for most interfaces, you do not want to allow
native objects to be considered as objects implementing interfaces.
For example, you don’t want

  document.documentElement.appendChild({
    nodeType: 1,
    nodeName: 'div',
    appendChild: function(n) { … },
    removeChild: function(n) { … },
    …
  });

to work.  So an annotation is required to indicate which interfaces can
be implemented by native objects.

> > > If you specifically need to know whether a given ECMAScript
> > > property exists on the native object,
> This is our case.
>
> > > then that’s something currently
> > > outside the realms of Web IDL.
> propertyIsEnumerable and "for .. in" seem to handle the properties in ES, or?

If you’re happy making requirements just for the ECMAScript language
binding of the Geolocation spec, then that will work.  Note that the
Java language binding of the PositionOptions interface would be:

  public interface PositionOptions {
    void setEnableHighAccuracy(boolean b);
    boolean getEnableHighAccuracy();
    void setTimeout(int i);
    int getTimeout();
    void setMaximumAge(int i);
    int getMaximumAge();
  }

and all of the methods would need to be implemented, so omitting
attributes doesn’t really make sense outside of ECMAScript.

> My understanding is that the PositionOptions will never be
> instantiated like var p = new PositionOptions();
>
> We would use it only as you quoted:
> >>  navigator.getCurrentPosition(a, b, { enableHighAccuracy: true,
> >>                                       timeout: 5 });
>
> Shall we then use the following?
> [Callback=PropertyOnly]
> interface PositionOptions {
>   attribute boolean enableHighAccuracy;
>   attribute long timeout;
>   attribute long maximumAge;
> };

PropertyOnly is (or should be) only useful to control how interfaces
with a single operation can be implemented by an ECMAScript object.  It
indicates that a Function object’s [[Call]] is not the implementation of
the single operation on such interfaces, and that instead a property
with the name of the operation is.

At one point native objects couldn’t implement an interface if there
were attributes on there; I probably need to update the wording for
[Callback] to indicate that PropertyOnly/FunctionOnly really only apply
for those single-operation interfaces.

Thanks,

Cameron

--
Cameron McCormack ≝ http://mcc.id.au/


________________________________________

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 Thursday, 18 June 2009 07:54:49 UTC