I have read the discussion so far, but would like to come back to the
strawman itself because I believe that it starts with a problem
statement that's incorrect and misleading the discussion. Correctly
describing the current situation would help in the discussion of
possible changes, in
This is all a bit off topic but performance does matter and folks seem to be
underestimating the wealth of community knowledge that exists in this area.
Who underestimates?
Sorry, this wasn't meant to slight anyone. I have spent a career standing on
the shoulders of Allen and his colleagues.
On 16 May 2011 17:42, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/16/11 4:38 PM, Wes Garland wrote:
Two great things about strings composed of Unicode code points:
...
If though this is a breaking change from ES-5, I support it
whole-heartedly but I expect breakage to be very limited.
On May 16, 2011, at 7:55 PM, Peter Michaux wrote:
On Mon, May 9, 2011 at 6:02 PM, Brendan Eich bren...@mozilla.com wrote:
Yes, and we could add call/cc to make (some) compiler writers even happier.
But users would shoot off all their toes with this footgun, and some
implementors would be
On 5/17/11 10:40 AM, Wes Garland wrote:
On 16 May 2011 17:42, Boris Zbarsky bzbar...@mit.edu
Those aren't code points at all. They're just not Unicode.
Not quite: code points D800-DFFF are reserved code points which are not
representable with UTF-16.
Nor with any other Unicode encoding,
On May 16, 2011, at 8:13 PM, Allen Wirfs-Brock wrote:
I think it does. In another reply I also mentioned the possibility of tagging
in a JS visible manner strings that have gone through a known encoding
process.
Saw that, seems helpful. Want to spec it?
If the strings you are combining
On 5/17/11 1:05 PM, Brendan Eich wrote:
If the strings you are combining from different sources have not been
canonicalize to a common encoding then you better be damn care how you combine
them.
Programmers miss this as you note, so arguably things are not much worse, at
best no worse,
On May 17, 2011, at 10:22 AM, Boris Zbarsky wrote:
Yes. And right now that's how it works and actual JS authors typically don't
have to worry about encoding issues. I don't agree with Allen's claim that
in the long run JS in the browser is going to have to be able to deal with
arbitrary
On 5/17/11 1:27 PM, Brendan Eich wrote:
On May 17, 2011, at 10:22 AM, Boris Zbarsky wrote:
Yes. And right now that's how it works and actual JS authors typically don't have to
worry about encoding issues. I don't agree with Allen's claim that in the long run
JS in the browser is going to
On May 17, 2011, at 10:37 AM, Boris Zbarsky wrote:
On 5/17/11 1:27 PM, Brendan Eich wrote:
On May 17, 2011, at 10:22 AM, Boris Zbarsky wrote:
Yes. And right now that's how it works and actual JS authors typically
don't have to worry about encoding issues. I don't agree with Allen's
On 5/17/11 1:40 PM, Brendan Eich wrote:
On May 17, 2011, at 10:37 AM, Boris Zbarsky wrote:
On 5/17/11 1:27 PM, Brendan Eich wrote:
On May 17, 2011, at 10:22 AM, Boris Zbarsky wrote:
Yes. And right now that's how it works and actual JS authors typically don't have to
worry about encoding
On May 17, 2011, at 10:43 AM, Boris Zbarsky wrote:
On 5/17/11 1:40 PM, Brendan Eich wrote:
Where do you read forcing? Not in the words you cited.
In the substance of having strings in different encodings around at the same
time. If that doesn't force developers to worry about encodings,
On May 17, 2011, at 10:47 AM, Brendan Eich wrote:
On May 17, 2011, at 10:43 AM, Boris Zbarsky wrote:
On 5/17/11 1:40 PM, Brendan Eich wrote:
Where do you read forcing? Not in the words you cited.
In the substance of having strings in different encodings around at the same
time. If that
On May 17, 2011, at 4:57, Peter Michaux petermich...@gmail.com wrote:
The goal of pleasing compiler writers should be
to make it possible to compile existing languages like Perl, Ruby,
Python and Scheme to JavaScript. These languages are the ones that
people know and really want to use and
I would much prefer changing UCS-2 to UTF-16, thus formalizing that
surrogate pairs are permitted. That'd be very difficult to break any existing
code and would still allow representation of everything reasonable in Unicode.
That would enable Unicode, and allow extending string literals and
On 5/17/11 1:47 PM, Brendan Eich wrote:
On May 17, 2011, at 10:43 AM, Boris Zbarsky wrote:
On 5/17/11 1:40 PM, Brendan Eich wrote:
Where do you read forcing? Not in the words you cited.
In the substance of having strings in different encodings around at the same
time. If that doesn't
On 17 May 2011 12:36, Boris Zbarsky bzbar...@mit.edu wrote:
Not quite: code points D800-DFFF are reserved code points which are not
representable with UTF-16.
Nor with any other Unicode encoding, really. They don't represent, on
their own, Unicode characters.
Right - but they are still
On 5/17/11 2:12 PM, Wes Garland wrote:
That said, you can encode these code points with utf-8; for example,
0xdc08 becomes 0xed 0xb0 0x88.
By the same argument, you can encode them in UTF-16. The byte sequence
above is not valid UTF-8. See How do I convert an unpaired UTF-16
surrogate to
On 5/17/11 2:24 PM, Allen Wirfs-Brock wrote:
In the substance of having strings in different encodings around at
the same time. If that doesn't force developers to worry about
encodings, what does, exactly?
This already occurs in JS. For example, the encodeURI function produces
a string whose
Note: The W3C Internationalization Core WG published a set of requirements in
this area for consideration by ES some time ago. It lives here:
http://www.w3.org/International/wiki/JavaScriptInternationalization
The section on 'locale related behavior' is being separately addressed.
I think
Right - but they are still legitimate code points, and they fill out the
space required to let us treat String as uint16[] when defining the backing
store as something that maps to the set of all Unicode code points.
That said, you can encode these code points with utf-8; for example,
On May 17, 2011, at 12:00 PM, Phillips, Addison wrote:
Note: The W3C Internationalization Core WG published a set of requirements
in this area for consideration by ES some time ago. It lives here:
http://www.w3.org/International/wiki/JavaScriptInternationalization
You might want to
On Tue, May 17, 2011 at 10:50 AM, Axel Rauschmayer a...@rauschma.de wrote:
On May 17, 2011, at 4:57, Peter Michaux petermich...@gmail.com wrote:
The goal of pleasing compiler writers should be
to make it possible to compile existing languages like Perl, Ruby,
Python and Scheme to JavaScript.
We did.
Cf. http://lists.w3.org/Archives/Public/public-i18n-core/2009OctDec/0102.html
Addison
Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)
Internationalization is not a feature.
It is an architecture.
-Original Message-
From: Allen Wirfs-Brock
On 17 May 2011 14:39, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/17/11 2:12 PM, Wes Garland wrote:
That said, you can encode these code points with utf-8; for example,
0xdc08 becomes 0xed 0xb0 0x88.
By the same argument, you can encode them in UTF-16. The byte sequence
above is not valid
On 17 May 2011 15:00, Phillips, Addison addi...@lab126.com wrote:
2. Allowing unpaired surrogates is a *requirement*. Yes, such a string is
ill-formed, but there are too many cases in which one might wish to have
such broken strings for scripting purposes.
3. We should have escape syntax for
On 5/17/11 3:29 PM, Wes Garland wrote:
But the point remains, the FAQ entry you quote talks about encoding a
lone surrogate, i.e. a code unit, which is not a complete code point.
You can only convert complete code points from one encoding to another.
Just like you can't represent part of a UTF-8
The wrong conclusion is being drawn. I can say definitively that for the
string a\uD800b.
- It is a valid Unicode string, according to the Unicode Standard.
- It cannot be encoded as well-formed in any UTF-x (it is not
'well-formed' in any UTF).
- When it comes to conversion, the bad
On 17 May 2011 16:03, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/17/11 3:29 PM, Wes Garland wrote:
The problem is that UTF-16 cannot represent
all possible code points.
My point is that neither can UTF-8. Can you name an encoding that _can_
represent the surrogate-range codepoints?
On 5/17/11 5:24 PM, Wes Garland wrote:
UTF-8 and UTF-32. I think UTF-7 can, too, but it is not a standard so
it's not really worth discussing. UTF-16 is the odd one out.
That's not what the spec says.
Okay, I think we have to agree to disagree here. I believe my reading of
the spec is
On May 17, 2011, at 5:04 PM, Kyle Simpson wrote:
Regarding the - and = syntax, I just want to throw out one other concern
that I hope is taken into account, not only now, but for the future: I really
hope that we don't get to the point where we start adding functionality to
that style of
On 17 May 2011 20:09, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/17/11 5:24 PM, Wes Garland wrote:
Okay, I think we have to agree to disagree here. I believe my reading of
the spec is correct.
Sorry, but no... how much more clear can the spec get?
In the past, I have read it thus,
That is incorrect. See below.
Mark
*— Il meglio è l’inimico del bene —*
On Tue, May 17, 2011 at 18:33, Wes Garland w...@page.ca wrote:
On 17 May 2011 20:09, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/17/11 5:24 PM, Wes Garland wrote:
Okay, I think we have to agree to disagree here. I
The Private Names strawman currently combines a new runtime capability (using
both strings and private names as keys in objects) with several new syntactic
constructs (private binding declarations, #.id). At the March meeting, I
recall there was some support for the idea of separating these
Yes, I agree that separating them out is a good idea. Allen and I have been
working on this lately, and I've signed up to present private names at the
upcoming face-to-face. Our thinking has been along similar lines to what you
describe here.
Dave
On May 17, 2011, at 6:55 PM, Luke Hoban
Yes, I agree that separating them out is a good idea. Allen and I have
been working on this lately, and I've signed up to present private names at the
upcoming face-to-face. Our thinking has been along similar lines to what you
describe here.
Dave
Great - I see the new
Yes (from my perspective) but it is something we are still hashing out so don't
assume that will be the final proposal.
Allen
On May 17, 2011, at 7:33 PM, Luke Hoban wrote:
Yes, I agree that separating them out is a good idea. Allen and I have been
working on this lately, and I've signed
We had so much fun with feedback on my Unicode proposal I just have open
another one up for list feed back:
An updated version of the prototype for (formerly proto) operator proposal is
at http://wiki.ecmascript.org/doku.php?id=strawman:proto_operator
Mark;
Are you Dr. *Mark E. Davis* (born September 13, 1952 (age 58)), co-founder
of the Unicode http://en.wikipedia.org/wiki/Unicode project and the
president of the Unicode
Consortiumhttp://en.wikipedia.org/wiki/Unicode_Consortiumsince its
incorporation in 1991?
(If so, uh, thanks for giving me
On Sun, May 15, 2011 at 10:01 PM, Brendan Eich bren...@mozilla.com wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
That wiki page has no had extensive revisions in light of recent discussions
with Brendan, Allen, Dave Herman, and Bob Nystrom.
On Sun, May 15, 2011 at 11:49 PM, Brendan Eich bren...@mozilla.com wrote:
On May 15, 2011, at 10:01 PM, Brendan Eich wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
This looks pretty good at a glance, but it's a *lot*, and it's new.
On Mon, May 16, 2011 at 4:54 AM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com wrote:
[...]
Some simple examples of all use-cases would are needed I think.
Absolutely agree. I hope they are coming soon. Watch this space ;).
Regarding `new` keyword for the constructor (aka initializer),
If there were a more usable library variant of Object.create instead, it seems
the new syntax here would not be as necessary.
Instead of:
var o = myProto | {
a: 0,
b: function () {}
}
You could do:
var o = Object.make(myProto, {
a: 0,
b: function () {}
})
On 05/17/2011 09:49 PM, Luke Hoban wrote:
It seems the syntax is perhaps aiming to avoid needing to allocate an
intermediate object – but I imagine engines could potentially do that for
Object.make and friends as well if it was important for performance?
It's probably possible to do that.
44 matches
Mail list logo
