Re: Notes from Monday's meeting with TC39 folks

On Oct 7, 2009, at 10:50 PM, Maciej Stachowiak wrote:

> On Oct 7, 2009, at 9:57 PM, Cameron McCormack wrote:
>
>> With regards to how the undefined value should be coerced to a  
>> string,
>> Jonas said (paraphrasing):
>>
>> A lot of people have argued that we should always use the String
>> constructor so undefined gets converted to "undefined" (and similarly
>> for null).  I see logic in that too.  What makes the least amount of
>> sense is what we do in Gecko, where null comes "" and undefined
>> becomes "undefined".  I think we should recommend converting both to
>> the empty string and seeing what people say.  We can use union types
>> to handled undefined differently if necessary.  I think IE generally
>> stringifies both null and undefined.
>
> Many of the DOM Core and DOM Events interfaces specifically mandate  
> treating null the same as the empty string, and in at least some  
> cases this works interoperably.
>
> I think changing the behavior for undefined could be a compatibility  
> risk.

Jonas said IE generally stringifies null as well as undefined. If  
true, then what's the interoperable intersection semantics among  
browsers, if any? I asked this in the meeting because it's impossible  
to design for the majority or biggest minority use-case without survey  
data.

Even assuming coherent legacy with non-empty (and non-trivial)  
interoperable intersection semantics, the legacy semantics may be  
messy enough that we'd do better to deal with it one way, and with  
future APIs another way.


>> Later discussion, assuming that there was no Undefined type in the  
>> IDL,
>> suggested that the Null IDL type could be specified as either null or
>> undefined in ES, but when returned from the implementation to ES  
>> would
>> always be denoted using null.
>
> Since null and undefined are often treated differently, this seems  
> like a bad idea.

I said so too at the meeting. Mark Miller suggested a Bottom IDL type,  
a union of Null and Undefined. It was not clear to me that this would  
be used in new interfaces, even if it was what T? meant as shorthand:  
T? = T | Bottom for IDL type T.

I don't think we reached a conclusion here. Anyway, this was just a  
meeting of ES and WebIDL folks who happened to be in town, it was not  
decisive.


>> 3. “Deprecated”
>>   Same as category 2, but that it’s expected that the features could
>>   be removed from the platform (and Web IDL) at some point in the
>>   future.  (This category might be empty, and might as well be  
>> removed
>>   since they can just be category 2 features that are removed in a
>>   future revision of the spec.)
>
> I'm not sure anything is really in this category. If features can be  
> removed now, they should be removed now. If they can't be removed  
> now, it seems impossible to predict.

This category is empty. I heard about it and had the same reaction you  
did, and it was removed.


>> 4. Something like ES5’s Appendix B
>>   Not normative.  These would be advisory notes about things
>>   implementations might want to do for compatibility, but it would be
>>   up to the implementor to determine whether it was required.  If
>>   deemed required, then the implementor would follow the definitions
>>   in this section (that is, it’s defined how to do it, but optional
>>   whether it is required).  document.all falsey-ness was considered
>>   to be in this category, although currently that behaviour is
>>   specified in HTML5, not by virtue of any Web IDL feature.
>
> I don't like the idea of a non-normative appendix.

This section is normative. It gives normative specs for optional  
features, so if implementations support them (to risk chasing IE and  
win market share, or lose by failing to emulate other IE unspecified  
features) then they interoperate.

Gecko is not going to support callable collections so these can go here.


> Optional behaviors lead to interoperability problems and cause  
> trouble for authors and implementors alike.

The distinction is between required and optional feature. In both  
cases there is a normative spec.

I agree that options, profiles, and "levels" or "modes" create  
complexity in which hide interop bugs, due to spec bugs or just  
implementation bugs arising from the complexity.

On the other hand, we do not intend to support callable collections  
that WebKit and possibly Opera support, so either these don't get any  
normative spec, or they get an optional one. The latter seems better  
but I can live with the former.


> I think it's a giant failure that ES5 takes this approach to  
> anything - it's just a cheap way to maintain a smug sense of purity  
> without actually serving interoperability of the Web platform.  
> Interoperability is more important than wrinkling our noses at  
> distasteful legacy.

Fair enough, but bending current and future specs around legacy crap  
is the yin to your yang. I think we have to keep both sides in mind  
and strike a balance.


> In the specific case of document falsey-ness, I think it should be  
> mandatory, not optional (even though it is spec'd in HTML5, so this  
> discussion doesn't really apply).

You mean document.all falsyness? The way WebKit implements this  
violates ECMA-262 (there's no exemption for a host object in ToBoolean).

Considering your finding fault with ES5 for HTML5 and ES5 still  
conflicting over global code |this| binding (to something other than  
the global object, namely WindowProxy per HTML5), I think you are now  
in a glass house. Put down the stone. :-/


>> 5. Things considered for standardisation but rejected, and why
>>   Also not normative, and requirements wouldn’t be listed at all.
>>   (Not sure if any features were deemed to be in this category.)
>
> Anything rejected for standardization shouldn't be mentioned in the  
> spec.

The Reject category is informative, for WebIDL users and would-be  
extenders.

/be