Allen Wirfs-Brock wrote:
On Feb 20, 2012, at 3:14 PM, Brendan Eich wrote:
Note that the above say "invalid Unicode code point". 0xd800 is a
valid Unicode code point. It isn't a valid Unicode characters.
See
http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html#isValidCodePoint
On Feb 20, 2012, at 1:42 PM, Wes Garland wrote:
> On 20 February 2012 16:00, Allen Wirfs-Brock wrote:
>
> ...
> Observation -- disallowing otherwise "legal" Unicode strings because they
> contain code points d800-dfff has very concrete implementation benefits: it's
> possible to use UTF-16 to
On Feb 20, 2012, at 3:14 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> On Feb 20, 2012, at 12:32 PM, Brendan Eich wrote:
>>
>>> Allen Wirfs-Brock wrote:
...
You are essentially saying that a compiler targeting ES for a language X
that includes a string data type that doe
As Brendan's link indicates, JSON is specified by RFC 4627, not by the
ECMAScript Language Specification. JSON is widely used for data exchange with
and between systems that have nothing to do with ECMAScript and the proposed
BRS - see the middle section of
http://www.json.org/
So the only thin
Allen Wirfs-Brock wrote:
On Feb 20, 2012, at 12:32 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
You are essentially saying that a compiler targeting ES for a language X that
includes a string data type that does not confirm to your rules (for example,
by allowing occurrences of surr
On 20 February 2012 16:00, Allen Wirfs-Brock wrote:
> My sense is that there are a fairly large variety of string data types
> could be use the existing ES5 string type as a target type and for which
> many of the String.prototuype.* methods would function just fine The
> reason is that most of
On Feb 20, 2012, at 12:32 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>>
>> ...
>
>> You are essentially saying that a compiler targeting ES for a language X
>> that includes a string data type that does not confirm to your rules (for
>> example, by allowing occurrences of surrogate c
Allen Wirfs-Brock wrote:
On Feb 20, 2012, at 10:52 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
Another way to express what I see as the problem with what you are
proposing about imposing such string semantics:
Could the revised ECMAScript be used to implement a language that
had s
On Feb 20, 2012, at 8:37 AM, Brendan Eich wrote:
> BRS makes 21-bit chars, so just as String.prototype.charCodeAt returns a code
> point, String.fromCharCode takes actual code point arguments.
>
> Again I'd reject (dynamically in the case of String.fromCharCode) any in
> [0xd800, 0xdfff]. Other
I mistyped.
I wrote "if ( f ) {" instead of "if ( ! f ) {"
So when I compare objects with a function, I'm in the "else" part and
I check "if f( item, max ) == 1" instead of "if item < max".
Array.prototype.max = function ( f ) {
var max = this[ 0 ];
var i;
var l = this.length;
var item
On Feb 20, 2012, at 10:52 AM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
> ...
>> Another way to express what I see as the problem with what you are proposing
>> about imposing such string semantics:
>>
>> Could the revised ECMAScript be used to implement a language that had
>> similar but
In that case, you should not even compare tomatoes and potatoes, a side
effect you may have when greater or "less than" is used in your example or
sort, without any callback to invoke able to compare, could produce:
unexpected results.
"a" and "0a" ... who's first here ?
[0] and {length:0}, who is
Hi,
I think it'd be nice to have a second argument for
Array.prototype.sort. It'd be a function used to map the values before
the comparison.
var array = [ /* w/e */ ];// array containing objects
var f = function ( item ) { /* w/e */ };// a function that takes an
item from array as argument and r
Because I'm not talking of arrays containing only numbers.
On Mon, Feb 20, 2012 at 8:29 PM, Rick Waldron wrote:
> Why add new api surface when this works as is:
>
> Math.max.apply( null, [ 1, 2, 3, 4 ] );
> // 4
>
>
> Math.min.apply( null, [ 1, 2, 3, 4 ] );
> // 1
>
>
>
> On Mon, Feb 20, 2012 at
Why add new api surface when this works as is:
Math.max.apply( null, [ 1, 2, 3, 4 ] );
// 4
Math.min.apply( null, [ 1, 2, 3, 4 ] );
// 1
On Mon, Feb 20, 2012 at 2:25 PM, Xavier MONTILLET
wrote:
> Hi,
>
> I think it'd be nice to have Array.prototype.max and Array.prototype.min.
>
> What they
Hi,
I think it'd be nice to have Array.prototype.max and Array.prototype.min.
What they would do is this:
Array.prototype.max = function ( f ) {
return this.sort( f )[ this.length - 1 ];
};
Array.prototype.min = function ( f ) {
return this.sort( f )[ 0 ];
};
Of course, that's not how t
Allen Wirfs-Brock wrote:
I really don't think any Unicode semantics should be build into the
basic string representation. We need to decide on a max element size
and Unicode motivates 21 bits, but it could be 32-bits. Personally,
I've lived through enough address space exhaustion episodes in
Allen Wirfs-Brock wrote:
For the moment, I'll simply take Wes' word for the above, as it logically makes
sense. For some uses, you want to process all possible code points (for
example, when validating data from an external source). At this lowest level
you don't want to impose higher level
On Feb 20, 2012, at 8:20 AM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>>> Last year we dispensed with the binary data hacking in strings use-case. I
>>> don't see the hardship. But rather than throw exceptions on concatenation I
>>> would simply eliminate the ability to spell code units w
Andrew Oakley wrote:
Issues only arise in code that tries to treat a string as an array of
16-bit integers, and I don't think we should be particularly bothered by
performance of code which misuses strings in this fashion (but clearly
this should still work without opt-in to new string handling).
Gavin Barraclough wrote:
What it might do, however, is eliminate the ambiguity about the
intended meaning of "\uD800\uDc00" in legacy code. If "full unicode
string mode" only supported \u{} escapes then existing code that uses
\u would have to be updated before it could be used in that
Allen Wirfs-Brock wrote:
Last year we dispensed with the binary data hacking in strings use-case. I don't see the
hardship. But rather than throw exceptions on concatenation I would simply eliminate the
ability to spell code units with "\u" escapes. Who's with me?
I think we need to be ca
On 20 February 2012 09:56, Andrew Oakley wrote:
>
> While this is being discussed, for any new string handling I think we
> should make any invalid strings (according to the rules in Unicode)
> cause some kind of exception on creation.
>
Can you clarify which definition in the Unicode standard y
Most content actually only tries to access characters of a string like this:
for (var i = 0; i < str.length(); i++) {
str[i];
}
While a naive implementation using UTF-8 encoding strings would be
O(n^2) if the previous lookup result was cached it is possible to
achieve a reasonably fast O(
On 19 February 2012 16:34, Brendan Eich wrote:
> Wes Garland wrote:
>
>> Is there a proposal for interaction with JSON?
>>
>
> From http://www.ietf.org/rfc/rfc4627, 2.5
>
*snip* - so the proposal is to keep encoding JSON in UTF-16. What happens
if the BRS is set to Unicode and we want to encode
On 20 February 2012 00:45, Allen Wirfs-Brock wrote:
>
> 2) Allow invalid unicode characters in strings, and preserve them over
> concatenation – ("\uD800" + "\uDC00").length == 2.
>
> I think 2) is the only reasonable alternative.
>
I think so, too -- especially as any sequence of Unicode code
26 matches
Mail list logo
