W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: WebIDL editorial feedback

From: timeless <timeless@gmail.com>
Date: Thu, 14 Jul 2011 19:44:01 -0400
Message-ID: <CAACrNNfnUkQhxs5y3aDTmUML92d452RuNoHVbdz4JmRs3skQeg@mail.gmail.com>
To: public-script-coord@w3.org
> It is the responsibility of specifications using Web IDL to state
> which global environment (or, by proxy, which global object)
> each platform object is associated with.

s/state which/state to which/; s/associated with/associated/

> These properties are not “real” own properties on the object,

[global] You use `own` in a magic way which isn't really correct in
English. I'd

almost want you to use <var>own<var> or <tt> or something (or rephrase it) --

possibly even 'Own' instead of 'own'.

> but are made to look like they are by being exposed by the
> [[GetOwnProperty]] internal method.

> Platform objects implementing an interface that support indexed or
> named properties defy being fixed; if Object.freeze, Object.seal or
> Object.preventExtensions is called on one, these the function MUST

s/these// or s/one, these/one of these objects,/

> throw a TypeError.

--

> Future versions of the ECMAScript specification may define a total order for

property enumeration.

Should there be a feature of the spec to enable one to satisfy WebIDL
in case the

ECMAScript spec isn't compatible w/ 4.7.6 Property enumeration?

  e.g., "If ECMAScript defines a total oder for property enumeration,
perform its

steps instead of the following:"

> For each exception field whose identifier is not “constructor”

I haven't quite figured out why this doesn't also mention "prototype"
(see similar

comment on earlier objects).

> that is defined on the exception, there MUST be a corresponding
> property on the exception interface prototype object, whose
> characteristics are as follows:

--

> then the global environment
> the newly created object is associated with is the same one that the
> exception interface object itself is associated with.

s/the newly/of the newly/; s/is.*that/MUST be the same as for/; s/is.*with//

> The value of the internal [[Prototype]] property of the exception object
> MUST be the exception interface prototype object from the global environment
> the exception object is associated with.

s/the exception object is associated with/of the exception/

> 4.12. Handling exceptions

The example here uses try{} blocks to catch each exception except for
the last, some

of the earlier example blocks in the document did not do this, i'd
request that they

be adapted to do so.

> 5. Java binding

This isn't a hat I've worn in about a decade.

> A conforming Java implementation MUST have a public Java interface
> corresponding to to every IDL interface that is supported, whose name
> is the Java escaped identifier of the IDL interface and which resides
> in the Java package corresponding to the interface’s enclosing module
> (or the default package, if there is no enclosing module).

The prose here is of a rather different form than the prose for
5.2.20. Arrays — T[].

> If the IDL interface has one or more static operations declared on it,
> then there MUST also exist a public, abstract Java class, whose name is
> the concatenation of the identifier of the IDL interface and the string
> "Utils", and which also resides in the Java package corresponding to the
> interface’s enclosing module (or the default package, if there is no
> enclosing module). This class is known as the utility class for the IDL
> interface.

Nothing in the spec so far has prevented people from creating FooUtils
interfaces,

and in fact, I believe some have been suggested. Which makes me worry about

collisions if someone has:

interface Foo {
  static void x();
}
interface FooUtils {
  void y();
}

I'm not quite sure why one would do this, but, oh well.

(I think WindowUtils has been mentioned for example...)

> 5.4.3 Attributes

> The tentative name of the method is a U+0067 LATIN SMALL G ("g") character,
> followed by a U+0065 LATIN SMALL E ("e") character, followed by a U+0074 LATIN
> SMALL T ("t") character, followed by the first character of the identifier
> of the attribute uppercased (as if passed to the
> java.lang.Character.toUpperCase() method), followed by the remaining

If someone is stupid and has:

interface someI {
attribute boolean i;
attribute boolean I;
}

Will this mapping fall appart horribly? :)

I was disappointed that I couldn't give you a dotless i here. (I
reached 'A. IDL

grammar').

> characters from the identifier of the attribute.

---

> 5.6. User objects implementing interfaces
> A Java user object that implements an IDL interface MUST be of a Java
> class that implements the Java interface that corresponds to the IDL
> interface.

interface A {};
interface B {};
A implements B;

If I have:
class MyA extends A {}, does the text above properly require me to in fact do:
class MyA extends A implements B {} ?

> The Java class MUST have only the public modifier.
> If the IDL exceptioninherit from another exception,

s/exception/exception /
s/inherit/inherits/

> The editor would like to thank the following people for contributing to
> this specification: ... Allen Wirfs-Brock, Collin Xu, Boris Zbarsky.

Lists normally have an 'and' clause :)

note: I will be at a W3 WG F2F next week. So I won't be able to do
much over that

period. Also, I'm not actually subscribed to this mailing list (I'll try to fix

that...).
Received on Thursday, 14 July 2011 23:44:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC