- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 19 Feb 2010 17:27:06 -0800
- To: Brendan Eich <brendan@mozilla.org>
- Cc: Simon Pieters <simonp@opera.com>, Boris Zbarsky <bzbarsky@mit.edu>, "Mark S. Miller" <erights@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Feb 19, 2010, at 4:32 PM, Brendan Eich wrote:
> On Feb 19, 2010, at 3:53 PM, Simon Pieters wrote:
>
>> On Fri, 19 Feb 2010 17:40:16 +0100, Boris Zbarsky
>> <bzbarsky@mit.edu> wrote:
>>
>>>> 'f' in 'x'
>>>> TypeError: Cannot use 'in' operator to search for 'f' in x
>>>
>>> This is more serious, since it could hinder object-detection of
>>> the new properties....
>>>
>>> Thank you for bringing that up.
>>
>> It would hinder object detection using if ('px' in foo.top), but
>> object detection using if (foo.top.px != undefined) would work fine.
>
> There are lots of ways to detect, but breaking compatibility and
> breaking invariants such as ('px' in foo.top) -> throw TypeError are
> not to be done lightly.
>
> It is not clear to me why a better API needs to extend property
> reference syntax off the deep end of this pier. What's the attraction?
>
> Conversion of number to string and back can be optimized, and is
> being optimized in competitive JS VMs.
We definitely do need an API that works with numbers. Conversion, no
matter how optimized, is a waste. Furthermore, it's not just a simple
conversion, the units part of the string must be removed and then re-
added. I don't think there is any question that we need to bypass all
that and enable direct use of numeric values.
The question is just whether to hang it off the string-based API in
this slightly odd way, or to add a new parallel API. Please don't
throw out the valid use case baby with the quirky solution bathwater.
My design taste and compatibility concerns would lean towards a new
parallel API, but I'm willing to give proponents of extended strings a
chance to demonstrate that it is a viable option.
Regards,
Maciej
Received on Saturday, 20 February 2010 01:27:39 UTC