- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 08 Sep 2011 18:33:52 +1000
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- CC: public-script-coord@w3.org, Anne van Kesteren <annevk@opera.com>
Hi Allen.
Thanks for the detailed feedback!
For all of the issues below that I've resolved, please let me know if
the resolution is satisfactory.
I split this mail into separately tracked comments (LC-26, and LC-45
through LC-64, which are mostly but occasionally not in the same order
as you report in this mail); see
http://dev.w3.org/cvsweb/2006/webapi/WebIDL/lc1.txt
for the comments attributed to you, and correlated them to the
changelog, if you wish to check the exact change:
http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.html
Sorry for not noting each commit individually in the body of the mail below.
On 24/08/11 1:44 AM, Allen Wirfs-Brock wrote:
> Where is the meaning of green, grey, and blue backgrounds defined?
I've added a "Typographical conventions" section.
> Clause 2
>
> It isn’t clear to me that the phrase “conforming <language>
> implementation” has any real utility relative to any specific WebIDL
> fragment. It apparently means that the language binding works as
> specified for that API fragment but it doesn’t necessarily mean that
> the actual functionality accessed through that API is conforms to its
> corresponding specification.
>
> The two actual uses of “conforming ECMAScript implementation” in this
> specification seem redundant. The usage in the first paragraph of
> clause 4 is essentially a restatement of the definition from clause
> 2. The only other usage in the first paragraph of 4.1 is unnecessary
> as it has already been established that clause 4 defines the behavior
> of a conforming ECMAScript implementation. The usages of “conforming
> Java implementation” seem to be similarly insignificant.
>
> My sense is that the definition of conformance in clause 2 may be
> appropriate but the current usage of the phrases in in clauses 4 and
> 5 are unnecessary and perhaps undesirable as the usagr isappears
> relative to only a couple specific requirements when in fact all of
> the requirements of these clauses are necessary for conformance.
Yes, I think this assessment is accurate. Nearly all of the
requirements in sections 3, 4 and 5 do not explicitly state which
conformance class they apply to. The couple of references in sections 4
and 5 to "conforming XXX implementation" might be a distraction. I have
removed them.
> Clause 3, paragraph 1
> “describe the interfaces (in the object-oriented sense)” what is the
> “object-oriented sense” and who defines its. For example, see
> http://www.google.com/search?q=object+oriented+interface+definition
Good question. :) I mean something more abstract than, say, a Java
interface, or the IDL interface. More like the set of ways that you can
interact with objects as defined by the API. Do you have any suggested
wording? (Maybe just delete the parenthetical?)
> Clause 3 Example
>
> Because this section is, in theory, independent of any specific
> language binding, I wonder if it is really appropriate to only talk
> about the ECMAScript binding in the example. It would clarify that
> this is a language independent interface definition if the
> paragraphs describing the ECMAScript binding of the example module
> were immediately followed by paragraphs about the Java binding.
I added a couple of sentence about the Java binding details.
> Clause 3.1
>
> “For constants, ... the final identifier token before the semicolon
> at the end of the declaration determines the identifier.”
> but in:
> const type constant-identifier = value;
> the value may be one of the identifiers “true”, “false”, or “null”
> so the above statement is not always correct.
“true”, “false” and “null” are not considered as identifier tokens in
Appendix A. The green box should help if people are confused by this
anyway.
> Clause 3.1
> “The qualified name of every module, interface, dictionary, exception
> and typedef MUST NOT be the same as the qualified name of any other
> interface, dictionary, exception or typedef. ”
>
> in what context? All WebIDL code that is ever written. Within a
> single specification? Among all W3G specifications? Implicitly, what
> outer-most scope are you talking about in relationship to this
> statement.
In the set of IDL fragments that the given implementation supports. I
will say this explicitly.
> Clause 3.2 Modules
>
> I appreciate the desire to eliminate modules, if they are currently
> [not] being used by any specifications. However, this also seems short
> sighted. In ECMA TC39 we generally try to be very conservative in
> adding new names to the global name space (ie, properties of the
> global object) because of the high probability that such names will
> clash with user defined global names used by existing web pages. To the
> extend that WebIDL names are converted to global ECMAScript names
> (for example,interface names manifesting as ECMAScript constructor
> functions), WebIDL and W3C specification have the same problem. Some
> sort of name space qualification of global names introduced by W3C
> specifications seems essential. If it isn’t accomplished via WebIDL
> modules it needs to be specified in some other manner.
I haven't seen any support expressed so far for using Web IDL modules
with [NamespaceObject] so that interface object properties can be put on
an object other than the global object.
I guess what I wonder is: if ECMAScript modules become the accepted way
to put JS library APIs in a namespace and to import them for use, will
that also be the way that future Web platform APIs are namespaced too?
This is something that I don't think has been discussed yet. I think it
is premature for Web IDL to include a namespacing mechanism if we're not
sure yet what we want to achieve for Web platform APIs in terms of
namespacing.
> Clause 3.3 Interfaces
> First paragraph: “An interface is a definition (matching Interface) that defines an interface that objects in the system can implement. ”
>
> This definition seems highly circular. “An interface is a definition … that defines an interface...”
> What definition applies to the second occurrence of “interface”? Also this seems to be the first normative use of “object(s)” and it does not have a definition. What is an “object”. This is important because subsequent paragraphs make various assertions about objects within any language binding qualification. How does the WebIDL concept of “object” relative to specific language bindings and the rules and capabilities of those languages?
The first "interface" is the IDL interface definition and the second one
is more abstract. I agree that this sentence here is unsatisfying. I
welcome suggested wording replacements, especially since I might
flounder with some fundamental terminology. Some proposed replacement
text, which I have put into the spec:
IDL fragments are used to describe object oriented systems. In such
systems, objects are entities that have identity and which are
encapsulations of state and behavior. An interface is a definition
(matching Interface) that declares some state and behavior that an
object implementing that interface will expose.
interface identifier {
interface-members...
};
An interface is a specification of a set of interface members
(matching InterfaceMembers), which are the constants, attributes and
operations that appear between the braces in the interface
declaration. Attributes describe the state that an object
implementing the interface will expose, and operations describe the
behaviors that can be invoked on the object. Constants declare
named constant values that are exposed as a convenience to users
of objects in the system.
> Third paragraph: “Objects implementing the interface will have members”. What is an object “member”?
I've replaced that sentence with this text:
Interfaces in Web IDL describe how objects that implement the
interface behave. In bindings for object oriented languages, it is
expected that an object that implements a particular IDL interface
provides ways to inspect and modify the object's state and to
invoke the behavior described by the interface.
Note
In the Java language binding, for example, this is achieved by
having the object implement a Java interface that has methods for
reading and writing attribute values and to invoke an operation.
> It isn’t clear whether or not an interface definition can specify a member with the same name as an inherited member and if so, what meaning is applied to such definitions.
I think I want to state that this is possible, and that language
bindings expose the derived member but may also expose the inherited
member, depending on whether that is appropriate for the particular
language. (There are already some instances of overridden operations
and attributes in Web platform APIs, for example in some of the
HTMLCollection descendants.) Would the following text work (which I
have added)?
Interfaces may specify an interface member that has the same name as
one from an inherited interface. Objects that implement the derived
interface will expose the member on the derived interface. It is
language binding specific whether the overridden member can be
accessed on the object.
Example
Consider the following two interfaces.
interface A {
void f();
void g();
};
interface B : A {
void f();
void g(DOMString x);
};
In the ECMAScript language binding, an instance of B will have a
prototype chain that looks like the following:
[Object.prototype: the Object prototype object]
^
[A.prototype: interface prototype object for A]
^
[B.prototype: interface prototype object for B]
^
[instanceOfB]
Calling instanceOfB.f() in ECMAScript will invoke the f defined on
B. However, the f from A can still be invoked on an object that
implements B by calling `A.prototype.f.call(instanceOfB);`.
In the Java language binding, the two IDL interfaces will correspond
to the following Java interfaces:
public interface A {
void f();
void g();
}
public interface B extends A {
void f();
void g(String x);
}
Calling instanceOfB.f() in Java will invoke the f defined on B. Due
to the way method overriding is defined to work in Java, there is no
way to call the f defined on A on an object that implements B.
Since the signature of g is different in A and B, however, both can
be called with, for example, instanceOfB.g() and instanceOfB.g("").
In both languages, the f and g from the derived interface B are
always accessible.
> “Note that general multiple inheritance of interfaces is not
> supported, and<<1:objects also cannot implement arbitrary sets of
> interfaces>>.<<2: Objects can be defined to implement a single given
> interface A, which means that it also implements all of A’s
> inherited interfaces. In addition, an implements statement can be
> used to define that objects implementing ane interface will always
> also implement another interface.>>”
>
> <<1>> In what ways is this intended to restrict actual language
> objects? Does it mean that langauge objects that implement a WebIDL
> interface may only have “members” that correspond to the members of
> the interface?
I want to restrict specifications from requiring objects implement more
than one non-supplemental interface to reduce the "mashing multiple
inheritance into a single inheritance prototype chain" problem in
ECMAScript, unless they are in the same inheritance chain. So if you had
interface A { };
interface B { };
then the semantics of objects described by Web IDL would not allow an
object to implement both A and B. The only way to allow that would be
to require all As to implement B or vice versa, with an "implements"
statement.
(I guess this goes back to Jonas' idea of separating the "main" and
"supplemental" interfaces in Web IDL with syntax -- using "class" for
the former and "interface" for the latter. It might still be worth
thinking about.)
> <<2>> “can be defined...In addition...” Are you trying to say an an
> object must support either exactly one or exactly two interfaces?
> One provided by an interface definition and one provided by an
> implements statement? Or does this all mean something else entirely.
Yes, something like that. An object one "main" interface that it
implements (along with all the interfaces that one main one inherits
from). If there any of those interfaces are on the left hand side of an
"implements" statement, then the object must implement all of those
consequential interfaces too. Specifications cannot require objects
implement interfaces that violate those rules. That's what I want to say.
> “ane” should be “an”
(Fixed in a previous edit.)
> “Many object-oriented languages support interfaces, in which case the mapping of IDL interfaces to language interfaces is simple.”
>
> This seems like an inappropriate thing to say in normative text. If you really want to say it, make it a Note. Whether or not the mapping with be simple depends upon the specifics of the target language semantics. I don’t see why this needs to be stated.
I'll just remove that sentence.
> Partial Interfaces
>
> It isn’t clear why the keyword “partial” is needed or what it’s
> exact usage rules are. If partial interfaces are used does that mean
> that there is one Interface definition for a given identifier plus
> one or more PartialInterface definitions for the same identifier?
> What if there is more than one Interface? May a PartialInterface
> precede the Interface? It would seem that a human or machine could
> recognize and combine multiple Interface definitions using a common
> identifier without needing to see “partial”. Is the motivation of
> “partial” to provide explicit notice that a definition is not the
> complete definition of a logical interface. If that is the case, then
> it would seem to also be desirable to include “partial” on the
> Interface definition to also give notice that it is incomplete.
The "partial" is to indicate that this is not the primary definition of
the interface, but an augmentation of it. Maybe then the word "partial"
is wrong.
Currently, multiple interfaces with the same name without the "partial"
keyword is an error. Ordering does not matter. (I removed various
requirements about declarations needing to be before references and
forward declaring interfaces a while ago.)
While it is true that we could have it so that you can write multiple
interface definitions with the same name and without "partial"s and to
have that mean the same thing as choosing one of them to be the "main"
interface and the rest as partial, I think it is useful for the reader
of IDL fragments to be able to tell that the definition is extending an
already-defined interface.
Also, I think it is preferable not to require already published
interfaces to be updated to add a "partial" so that they can be extended
in other specifications. So I would rather leave it as it is.
It should be clear from the previous "Names" section that the qualified
name of two interface definitions cannot be the same.
I will add a sentence stating that the order of the main interface
definition and the partial interface definitions does not matter.
> The examples show two mutually referential interfaces. What are the
> naming order and reference rules for module members? 3.3.1 says that
> constants must be uniquely named. What about interfaces?
Section 3.1 states the requirements for uniqueness of definitions in
general. (Qualified names of interfaces must be unique.)
There should be no statements about order of declaration and reference
in the spec. I will add one to the Names section to explicitly state
that references can come before declaration. (Note that the set of IDL
fragments that are supported in an implementation is not ordered, either.)
> 3.3.1 Constants
>
> Why is the bnf production for the value of constant definition name “ConstExpr” when it is not an expression?
I think I just used the same symbol name that appeared in the OMG IDL
grammar. I can rename it to ConstValue.
> “The value of an integer token is an integer, parsed in a manner common to many programming languages, as follows: ” The red highlighted text adds no normative value.
I will strike it. (The algorithm used to be more detailed,
unncessarily, so the non-normative statement that there was no funny
business going on in it might have been helpful.)
> “1 Let S be the string value of the integer token.”
> Is “string value” well defined in this context? should this say like “Let S be the sequence of characters matched by the integer token”. Similarly for the float and string algorithms
> algorithm step 4.
It is not. I will use your phrasing.
> What if a character is out of bounds for the radix? For example: 0778899
The regular expression for matching the integer token in Appendix A
should already disallow that.
> Please verify that for the string algorithm you really means UTF-16
> and not UCS-2. In other words, you intend that any Unicode
> supplemental characters actually are encoded using multiple 16-bit
> code units.
Yes, that is what I want. (Since that is what the DOMString type takes.)
> Are constants implicitly “static”? They appear so, based upon the
> examples given in subsequent sections. If this is the case don’t you
> need to explicitly specify this just like you specify what it means
> for an operation to be explicitly “static”.
I guess they are kind of static, in that language bindings need not
expose them on instances. I have added the following:
Constants are not associated with particular instances of the
interface on which they appear. It is language binding
specific whether constants are exposed on objects implementing
interfaces.
Note
Both the ECMAScript and the Java language binding do however
allow constants to be accessed through objects implementing IDL
interfaces on which constants are declared. For example, with
the following IDL:
interface A {
const DOMString greeting = "hi";
};
the constant value can be accessed in ECMAScript and in Java either
as A.greeting or instanceOfA.greeting.
> 3.3.2 Attributes
> “An attribute is an interface member ... that is used to declare that objects implementing the interface will have an attribute with the given identifier whose value ”
> Perhaps the second “attribute” should be “member” in order to make this definition less circular.
OK.
> Inherits Getter. Isn’t the use of getters/setters to implement an
> attribute something that is determined by specific language bindings?
> In that case, why isn’t this expressed as an extended attribute? Is
> the intent is simply to say that an inherited readonly attribute is
> generalized to be writable? If so, why not simply provide for a
> “writable” or “not readonly” prefix rather than exposing the concept
> of getters for this purpose.
I think that's a fair point about the use of the word "getter".
With "writable" and "not readonly", I feel like it is not clear enough
that it is inheriting the prescribed behaviour for attribute assignment.
How about:
inherited attribute DOMString whatever;
? It doesn't say that it's inheriting the get behaviour, but it does
give a clue that the attribute is related to one from an inherited
interface.
> “If an implementation attempts to get or set the value of an
> attribute on an object implemented by user code...” The purpose of
> this paragraph is not clear and whether what it is saying applies
> uniquely to attributes. “objects implemented by user code” seems to
> be a key phrase. Is it simply trying to say that any exceptions
> generated by user code propagate back to user code? Is this really a
> general WebIDL rule. Wouldn’t this requirement be more appropriately
> stated in a language binding or perhaps in the section 7.1.3 of the
> HTML 5 specification HMTL 5 spec. Note that a similar requirement is
> also stated in 3.3.3.
I should have replaced "objects implemented by user code" with "user
object", since I now have that term. It is trying to say that if you had
[Callback]
interface A {
attribute DOMString x;
};
interface B {
void f(A a);
};
then if you do this
try {
var o = { };
Object.defineProperty(o, "x", { get: function() { throw 1 } });
f(o);
} catch (e) {
...
}
that the exception thrown in the getter will propagate up to f and then,
unless the description of f says otherwise, will propagate out to the
catch handler above. And similarly for other languages.
I think it is OK to require this for all language bindings. Do you
disagree?
> 3.3.3 Operations
> What is the meaning if an identifier is used to name a regular
> operation in an inherited interface and that same identifier is also
> directly used as the name of a special operation?
Do you mean:
interface A {
getter DOMString f(DOMString x);
};
interface B : A {
long f(DOMString x);
};
? When an instance of B is indexed with a string, then it will behave
as described for A.f.
Do you think this needs pointing out?
> “...if a value returned from invoking the operation cannot be
> converted to an IDL type...” Should this really be “converted to the
> representation defined by the language binding that corresponds to the
> specified return-type”
No, I think it is the "<language-specific-representation> to IDL value"
conversion that is being described.
> 3.3.4.1 Callers
> “Specifications SHOULD NOT use callers...” This should probably be the first paragraph of this section.
I think the sentence is just as visible where it is at the moment.
What I will do, however, is have a separate section in the specification
that lists the features that should not be used except for defining
legacy features. I think this will give even more visibility to which
features shouldn't be used.
> 3.3.6 Overloading
>
> “In the ECMAScript language binding, constructors can be overloaded
> too.” Why is ECMAScript specifically called out here? Could this
> also be the case for other languages? Perhaps it should say
> “Language bindings MAY support overloading of constructors”.
I think it is useful information for readers of this section to know.
One problem I have is that constructors are currently an ECMAScript
language binding specific feature. I am not sure that is right. I feel
like we maybe should make constructors a first class feature of the IDL,
say by writing
interface Event {
constructor (DOMString type, boolean bubbles, boolean cancelable);
...
};
rather than
[Constructor(DOMString type, boolean bubbles, boolean cancelable)]
interface Event {
...
};
and having the Java language binding expose constructors in some way.
(Probably as static methods on the utility class, which is where static
IDL operations go.)
Well, the syntax change (a special operation instead of an extended
attribute) is less important than the actual change for the feature not
to be ECMAScript-specific.
Opinions?
> 3.4 Dictionaries
>
> Why is it necessary to specify that the the key value pairs defined
> to be ordered? Particularly since ECMAScript does not define an enumeration
> ordering for object properties . Is there a important use case that
> requires that order is specified? Or how, (from the perspective of
> WebIDL) is this ordering observable?
>
> (The answers to some of my above questions are clearer after looking
> at 4.2.17. Perhaps a note here would eliminate such questions in
> readers of the spec.)
I'll add a note that some language bindings can expose an ordering of
dictionary members, and that this is why an order must be specified.
> Dictionaries also should not be allowed as the return-type of an
> operation. (Note that they are already restricted from being the type of
> attributes). The reason is to ensure that they are only used to specify
> values that pass into Web APIs and are not used to pass values back to
> user code.
The reason they are restricted from being the type of an attribute is
the same as for sequences; it would encourage wasteful usage such as:
dictionary Pos {
long x;
long y;
long z;
};
partial interface Window {
readonly attribute Pos pos;
};
alert([window.pos.x, window.pos.y, window.pos.z]);
which in this case would create three separate Pos objects each time the
property is accessed.
I don't see any specific need to disallow dictionary types from being
used as operation return types.
> 3.8 Objects implemeting interfaces
>
> “Language bindings define precisely how this check is made...”
> Perhaps this should be “Language bindings or the implementations of
> an IDL fragment define...”. I can imagine various different ways that
> an ECMAScript library implementing a Web API might recognize objects
> its specific objects that implement an interface. It don’t think the
> ECMAScript binding specification should be in the business of
> requiring such libraries to how to recognize their own objects.
Fair. I've done s/precisely how/when/.
> 3.9 Types
>
> “...all conversions necessary will be performed before the operation
> is invoked...” You don’t appear to actually define what it means to
> “invoke” an operation so it isn’t clear exactly what the “before” is
> referring to. Does the above statement imply that type conversions
> must be performed by the caller’s invocation mechanism rather than by
> a callee’s innovation prologue? I don’t think it should. A more
> reasonable interpretation would be that all conversions are performed
> before any of the specified functionality of the operation is carried
> out. If this is the intent, then you should be more explicit about
> it.
Yes, that is the intent. I tweaked the wording along the lines you suggest.
> 3.9,13 DOMString
>
> The first sentence says “..to be interpretd as UTF-16 encoded
strings...” but the next paragraph says “othing in this specificaiton
requires a DOMString value to be a valid UTF-16 string”. These two
statements seem contradictory with each other. Further more, you then go
on to give what appeares to be a UTF-16 to UTF-32 conversion algorithm.
MUST a DOMString be a valid UTF-16 or is it just that a DOMString MAY
contain such an encoding. Pick one. Also, why provide your own UtF-16 to
Unicode decoding algorithm. Where does this algorithm come into play?
Why not just reference the Unicode spec?
It's not the case that it MUST be valid UTF-16. UTF-16 is what many
APIs interpret DOMStrings as, which is what the "to be interpreted" part
is trying to say.
I changed the start of the paragraph to say:
The DOMString type corresponds to the set of all possible sequences of
16 bit unsigned integer code units. Such sequences are commonly
interpreted as UTF-16 encoded strings [RFC2781] although this is not
required.
The algorithm is referenced by some other specifications. I don't
believe the Unicode spec defines an algorithm that maps code units into
a sequence of Unicode characters, replacing invalid encodings with
replacement characters, does it? If you can point me to one, I will
just reference it.
> 4.2.3 boolean
> “IDL boolean values are represented by ECMAScript Boolean values”.
> However, the algorithm given to convert an ECMAScript value to an IDL
> boolean applies the Ecma-262 ToBoolean abstract operation to the
> value as the first step of the conversions. ToBoolean accepts any
> ECMAScript value as an argument. This seems to imply that IDL
> boolean values are representable by any ECMAScript value.
I've removed that sentence in this section and the following sections
you reference.
> The conversion from an IDL boolean to an ECMAScript value could be
> more clearly stated as: The IDL boolean value token true is converted
> to the ECMAScript true value and the IDL boolean value token false is
> converted to the ECMAScript false value.
I've changed it to be something like that.
> 4.2.4, 4.2.5, 4.2.6, 4.2.7, 4.2.8, 4.2.9, 4.2.10, 4.2.11, 4.2.12, 4.2.13
> See 4.2.3 comment, but regarding ToNumber instead of ToBoolean
>
> 4.2.4 byte
>
> Algorithm step 3, “octet” should be byte.
Yes it should.
> 4.2.10 and 4.2.11
> Why aren’t these sections symmetric in their description of how to choose the best approximation for values> 253-1?
They should be. I'll make 4.2.10 like 4.2.11.
> 4.2.12,
> I think you need a note to explain why you canonicalize NaNs to 0x7fc00000
I added a note.
> Why aren’t you cannonicalize NaNs when converting from IDL value to ECMAScript values?
Why do I need to canonicalise when there is only a single ECMAScript NaN
value?
> 4.2.13
> Step 2: “float” should be “double”
Changed.
> need a note about canonicalizing NaNs
Added the note here too.
> Steps 3-8 don’t do anything that wasn’t already done by ToNumber and
ToNumber always yields and ECMASript numbers are defined to be IEEE
doubles. so all you really need is a step 3: Return x.
So you can treat IEEE 754 double as exactly the same type as ECMAScript
Number? I haven't been thinking IDL float and double being the same
type as IEEE 754 floats/doubles. They're used in different contexts.
Although they do have the same sets of values.
So I will replace step 3 onwards with:
Return the IDL double value that has the same numeric value as x.
> Why aren’t you cannonicalize NaNs when converting from IDL value to ECMAScript values?
As above.
> 4.2.14 DOMString
> step 4: “same sequence of characters” should be “same sequence of code units”?
Yes.
> 4.2.17 Dictionary types.
>
> If bothers me that a complete copy of a dictionary must be made each
time a dictionary is passed in and that the occurrences of the copy is
observable by via ECMAScript accessor properties. Is this really
necessary? The main purpose of the copy seems to be to force a
ECMAScript/IDL type conversion of each value in the dictionary. Couldn’t
these conversions be done on demand within the specification of
operations that use dictionaries? However wise you seem to make making
any use of dictionaries unnecessarily expensive.
I posted my rationale for requiring copying all dictionary members (and
sequence elements) in David's "dictionary questions" thread on
public-script-coord.
I am still kind of on the fence. I'd appreciate others' views.
> 4.2.17 Sequence
>
> I’m also trouble by the observable and mandatory copy both in and
> out
for sequences. For a large sequence where only a few elements need to be
accessed the copying could could easily dominate the cost of the actual
operation.
Yeah...
> For an operation that returns a sequence, this spec. seems to
> require
that the operation first internally construct the sequence and then make
a copy of it. That seems unnecessarily.
I'm not sure what you mean here. Conceptually, internally, the
operation would construct an IDL sequence value. Then, when it is
returned to ECMAScript, it would be converted into an Array. The
internal construction of the sequence won't be observable, though, so I
don't think it matters. I think it's simpler to consider the conversion
of a whole, already constructed IDL sequence value.
> Note that [[Put]] operators even
on a new Array can be made observable via accessor properties that are
inherited from Object.prototype. To avoid this use [[DefineOwnProperty]]
instead for storing into the new Array. If the stores are not observable
then you should have to mandate a copy out on return as long as the
implementation of the operation doesn’t retain a reference to the
resuylt object.
I've fixed that.
> 4.2.18 Arrays
>
> “Note...most of the functions from the Array prototype object will
> not
perform any useful operation on read only arrays” -- “most” is incorrect
as the number of methods are are not sensitive to readonly-ness is
larger than the number that are. Perhaps “some of” would be better wording.
OK.
> I find the general concept of “platform array object” and the
> specific
mapping into ECMAScript objects a bit rough. The first paragraph says
they are “similar” to native Array objects. Can we enumerate all the
ways they are different. For example:
>
> they are never sparse
> their elements are always data properties
> an ECMAScrpt to WebIDL value conversion is always performed when store into an element
> Their [[Extensible]] property is always true.
* their [[Class]] is different
That's all that I can see at the moment.
I will add this list to a note.
> (BTW, why the latter restriction on [[Extensible]]? I understand why
> this might be desire for some usage of IDL Array but why all?
> Couldn’t this condition be represented by an extended attribute?).
I don't want to allow freeze() on non-fixed length IDL arrays, at least.
That would be confusing. The only time freeze() might be allowed is
if it is a fixed length IDL array, and the implementation will never
change the length of the array (remembering that while user code can't
resize fixed lengths arrays, the platform can). In that situation, the
user may wish to freeze the platform array object.
I don't know whether it is worth allowing this, though. Seems simpler
to me just to disallow freeze() always.
> 4.2.20.1 GetOwnProperty
>
> Why is the [[Configurable]] attribute of length and array index
properties reported as true when your[[DefineOwnProperty]] and
[[Delete]] reject any attempt to set them to any other values or to
delete them? If you property reported configurable then you shouldn’t
define to redefine [[Delete]]
That was due to the previously raised issue regarding proxies being able
to report non-configurable properties.
Since Tom's assurance that the next revision of the proposal will allow
non-configurable properties, I will be making length non-configurable.
I will still need to define [[Delete]] so that deletion of array index
properties is rejected (to ensure denseness of arrays), right?
> 4.2.20.2 Platform array object [[DefineOwnProperty]]
> Not precise enough, particularly with regard to deleting elements when the length changes This can’t be less precise than ECMAScript 15.4.5.1
Since the property descriptors returned by [[GetOwnProperty]] for the
array element properties are synthesised, rather than returning a
descriptor for a real own property, does [[DefineOwnProperty]] really
need the loops describing property deletion that ES 15.4.5.1 does?
Can you say exactly which aspects of 4.2.20.2 need to be more precise?
> 4.2.20.3 [[Delete]]
>
> You use “Reject” in this algorithm, but that is not a general
ECMAScript algorithm operation. It is only available for use in
algorithms like 15.4.5.1 because its meaning is explicitly defined in
the prose that precedes the algorithm.
Indeed, I've added a reference to the definition of Reject here.
> 4.2.21 Date
>
> First algorithm, step 4: “the smae millisecond as V” should probably be “the same time value as D”.
OK.
> 4.3.1 [AllowAny]]
> Editorial note: What if someone wanted to default all remaining types to a numeric type instead
Not supported currently, unless you just want to use "any" as the type
and discriminate within the operation itself.
If people bring up use cases for [AllowAny] on other types, let's
consider it then.
Received on Thursday, 8 September 2011 08:34:41 UTC