Nabble - Mozilla - ECMAScript 4 discussion

Re: Function.prototype, [[Call]] and [[Construct]]

2009-11-09T21:17:21Z

On Nov 10, 2009, at 12:10 AM, Garrett Smith wrote:

> On Mon, Nov 9, 2009 at 8:05 PM, Juriy Zaytsev <kangax.dev@...>
> wrote:
>> On Nov 9, 2009, at 6:50 PM, Garrett Smith wrote:
>>
>>> [[Construct]] of Function.prototype is not standardized.
>>>
>
> [...]
>
>>
>> If you look into Section 15 — Native ECMAScript Objects, you'll see
>> this
>> rather clear explanation:
>>
>> "[...] None of the built-in functions described in this section shall
>> implement the internal [[Construct]] method unless otherwise
>> specified in
>> the description of a particular function. None of the built-in
>> functions
>> described in this section shall initially have a prototype property
>> unless
>> otherwise specified in the description of a particular function.
>> [...]"

[...]

>
> So Function.prototype should not implement [[Construct]].

As far as I can see, no, it shouldn't.

WebKit (nightly) and Opera (10) conform here, throwing TypeError on
`new Function.prototype`, but Firefox (at least 3.5) erroneously
creates an object.

>
> Garrett

--
kangax
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Function.prototype, [[Call]] and [[Construct]]

2009-11-09T21:10:22Z

On Mon, Nov 9, 2009 at 8:05 PM, Juriy Zaytsev <kangax.dev@...> wrote:
> On Nov 9, 2009, at 6:50 PM, Garrett Smith wrote:
>
>> [[Construct]] of Function.prototype is not standardized.
>>

[...]

>
> If you look into Section 15 — Native ECMAScript Objects, you'll see this
> rather clear explanation:
>
> "[...] None of the built-in functions described in this section shall
> implement the internal [[Construct]] method unless otherwise specified in
> the description of a particular function. None of the built-in functions
> described in this section shall initially have a prototype property unless
> otherwise specified in the description of a particular function. [...]"
>

That's pretty clear. I had interpreted that as meaning the global
functions (eval, parseInt), but now I see that that text applies to
the whole section 15, not just the function properties (as I had
misread it).

> In fact, I mentioned this exact phrase when writing about bugs in various
> browsers, revealed through Sputniktests web runner
> (http://thinkweb2.com/projects/prototype/sputniktests-web-runner/#construct-and-prototype-of-builtins).
>
> And as I said in a post, Firefox and Chrome, for example, fail a whole bunch
> of tests due to most of built-in methods (like `Array.prototype.toString`,
> `parseInt` or `String.prototype.slice`) implementing [[Construct]] and
> having .prototype properties.
>

So Function.prototype should not implement [[Construct]].

Garrett
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Function.prototype, [[Call]] and [[Construct]]

2009-11-09T20:05:11Z

On Nov 9, 2009, at 6:50 PM, Garrett Smith wrote:

> [[Construct]] of Function.prototype is not standardized.
>
> The definition of Function.prototype does not define the expected
> behavior for [[Call]] or [[Construct]]. Instead, there is a
> description of what happens when it is invoked:
>
> | 15.3.4 Properties of the Function Prototype Object
> | The Function prototype object is itself a Function
> | object (its [[Class]] is "Function") that, when
> | invoked, accepts any arguments and returns undefined.
>
> Should Function.prototype implement [[Construct]]? Either way, the
> specification should state the outcome.

Yes, it's a slightly tricky one :) I was wading through Sputniktests
suite couple of days ago (when finishing web runner — http://thinkweb2.com/projects/prototype/sputniktests-web-runner/
) and noticed that there were assertions for exactly this kind of
compliance.

I even filed a bug with Sputniktests, thinking that they make
incorrect assumptions — http://code.google.com/p/sputniktests/issues/detail?id=11

However, then I realized that specs do in fact mention this
explicitly, although not directly under these specific sections.

If you look into Section 15 — Native ECMAScript Objects, you'll see
this rather clear explanation:

"[...] None of the built-in functions described in this section shall
implement the internal [[Construct]] method unless otherwise specified
in the description of a particular function. None of the built-in
functions described in this section shall initially have a prototype
property unless otherwise specified in the description of a particular
function. [...]"

In fact, I mentioned this exact phrase when writing about bugs in
various browsers, revealed through Sputniktests web runner (http://thinkweb2.com/projects/prototype/sputniktests-web-runner/#construct-and-prototype-of-builtins
).

And as I said in a post, Firefox and Chrome, for example, fail a whole
bunch of tests due to most of built-in methods (like
`Array.prototype.toString`, `parseInt` or `String.prototype.slice`)
implementing [[Construct]] and having .prototype properties.

[...]

--
kangax
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Function.prototype, [[Call]] and [[Construct]]

2009-11-09T15:50:24Z

[[Construct]] of Function.prototype is not standardized.

The definition of Function.prototype does not define the expected
behavior for [[Call]] or [[Construct]]. Instead, there is a
description of what happens when it is invoked:

| 15.3.4 Properties of the Function Prototype Object
| The Function prototype object is itself a Function
| object (its [[Class]] is "Function") that, when
| invoked, accepts any arguments and returns undefined.

Should Function.prototype implement [[Construct]]? Either way, the
specification should state the outcome.

Trying it out:

javascript: alert( new Function.prototype );

IE 6-8:
Error: Object doesn't support this action

Other browsers tested return an Object, indicating the [[Construct]]
is implemented.

The specification should state whether or not Function.prototype
implements [[Construct]], to clarify expected outcome, and to
encourage consistent implementations.

Garrett
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-08T18:54:29Z

Maciej Stachowiak wrote:

>
> On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:
>
>>
>> On 6 Nov 2009, at 19:24, Brendan Eich wrote:
>>
>>> On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:
>>>
>>>> Just in case some of you weren't aware, the CommonJS group has done
>>>> quite a bit of work and (bikeshedding) on this topic. Here's a link
>>>> to the wiki:
>>>>
>>>> http://wiki.commonjs.org/wiki/Binary
>>>>
>>>> ...
>
> Binary/B is the closest of the three proposals to mine, in that it has
> both mutable and immutable binary data containers. Here are a few key
> differences:
> ...
> Regards,
> Maciej

One note, Binary/C also originally had a mutable and an immutable type.
The mutable type was moved to IO/B/Buffer
(http://wiki.commonjs.org/wiki/IO/B/Buffer), when comparing to Binary/B,
Binary/C together with IO/B/Buffer is more equivalent a comparison.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-07T19:17:48Z

On Nov 7, 2009, at 6:53 PM, Ash Berlin wrote:

On 8 Nov 2009, at 02:21, Maciej Stachowiak wrote:

On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:

On 6 Nov 2009, at 19:24, Brendan Eich wrote:

On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:

http://wiki.commonjs.org/wiki/Binary

[snip]

[snip]
As a community (CommonJS) we'd be more than happy to go forward with a binary spec that came from (or at least has the blessing of) the ES groups

Binary/B is the closest of the three proposals to mine, in that it has both mutable and immutable binary data containers. Here are a few key differences:

(1) Binary/B does not have a cheap way to convert from the immutable representation (ByteString) to the mutable representation (ByteArray)
(2) In Binary/B, Array-like index access to ByteString gives back one-byte ByteStrings instead of bytes, likely an over-literal copying of String
(3) There are some seemingly needless differences in the interfaces to ByteString and ByteArray that follow from modeling on String and Array
(4) Binary/B has many more operations available in the base proposal (including charset transcoding and a generous selection of String and Array methods)
(5) Different names - Data/DataBuilder vs. ByteString/ByteArray

On (1): cheap conversion from mutable to immutable (DataBuilder.prototype.release() in my proposal) lets binary data objects be built up with a convenient mutation-based idiom, but then passed around as immutable objects thereafter.

Mutable to immutable or immutable to mutable? Assuming the former, how do you handle the differences in API/behaviour? each function checks wether it is now immutable?

Mutable to immutable. Immutable to mutable has to copy (or at least copy-on-write).

My proposal does it like this (where DataBuilder is the mutable variant and Data is the immutable):

DataBuilder.prototype.release()

Return a new Data with the same length and the same byte values as the DataBuilder passed as the this value. At the same time, the DataBuilder is reset to length 0.

Because the DataBuilder is reset to empty, the implementation can "steal" its underlying buffer for the new Data object, thus converting to immutable without a full copy. This matches the common pattern of assembling a new piece of binary data with mutation, then handing it out to possibly multiple other pieces of code as immutable.

On (2): I don't think a one-byte ByteString is ever useful, indexing to get the byte value would be much more helpful.

Couldn't agree more with you here - if for whatever reason you do want a one-byte ByteString, there is always substr/substring. This is something that came up recently in IRC and prompted me to start looking at making changes to the proposal - I was going to do that next week, so this coming up now is very good timing.

On (3), I think it's good for the mutable interface to be a strict superset of the the immutable interface.

Seems like a reasonable thing to do.

I'm glad we agree on these two points.

(4) and (5) are all points where perhaps neither proposal is at the optimum yet. On (4), I suspect the sweet spot is somewhere between my spartan set of built-in operations and the very generous set in Binary/B.

Agreed - this was the other thing i noticed - e.g. sorting a ByteArray isn't really an operation that makes a whole lot of sense to my mind.

Yep. I'm not even sure things like map(), filter() or reduce() are likely to work well. My own preference is to start the API very small, and add incrementally based on demonstrated need and clearly articulated use cases.

On (5), I'm not sure either set of names is the best possible, and I'm certainly not stuck on my own proposed names.

I'm not really bothered either way on this front, although 'Data' is much more likely to clash with existing code.

Yes, Brendan made this point and presented some good evidence in that direction. I think 'Data' doesn't work but 'Binary' or 'BinData' might.

Something worth bearing in mind is that Binary/B is implemented in 2 or 3 CommonJS platforms already, but I don't think any one is particularly attached to the behaviour so long as what comes out isn't wildly different.

What kind of differences do you think they would tolerate? Renaming the classes? Dropping/changing some methods?

Regards,

Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-07T18:53:59Z

On 8 Nov 2009, at 02:21, Maciej Stachowiak wrote:

On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:

On 6 Nov 2009, at 19:24, Brendan Eich wrote:

On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:

http://wiki.commonjs.org/wiki/Binary

[snip]

[snip]
As a community (CommonJS) we'd be more than happy to go forward with a binary spec that came from (or at least has the blessing of) the ES groups

Binary/B is the closest of the three proposals to mine, in that it has both mutable and immutable binary data containers. Here are a few key differences:

(1) Binary/B does not have a cheap way to convert from the immutable representation (ByteString) to the mutable representation (ByteArray)
(2) In Binary/B, Array-like index access to ByteString gives back one-byte ByteStrings instead of bytes, likely an over-literal copying of String
(3) There are some seemingly needless differences in the interfaces to ByteString and ByteArray that follow from modeling on String and Array
(4) Binary/B has many more operations available in the base proposal (including charset transcoding and a generous selection of String and Array methods)
(5) Different names - Data/DataBuilder vs. ByteString/ByteArray

On (1): cheap conversion from mutable to immutable (DataBuilder.prototype.release() in my proposal) lets binary data objects be built up with a convenient mutation-based idiom, but then passed around as immutable objects thereafter.

Mutable to immutable or immutable to mutable? Assuming the former, how do you handle the differences in API/behaviour? each function checks wether it is now immutable?

On (2): I don't think a one-byte ByteString is ever useful, indexing to get the byte value would be much more helpful.

Couldn't agree more with you here - if for whatever reason you do want a one-byte ByteString, there is always substr/substring. This is something that came up recently in IRC and prompted me to start looking at making changes to the proposal - I was going to do that next week, so this coming up now is very good timing.

On (3), I think it's good for the mutable interface to be a strict superset of the the immutable interface.

Seems like a reasonable thing to do.

(4) and (5) are all points where perhaps neither proposal is at the optimum yet. On (4), I suspect the sweet spot is somewhere between my spartan set of built-in operations and the very generous set in Binary/B.

Agreed - this was the other thing i noticed - e.g. sorting a ByteArray isn't really an operation that makes a whole lot of sense to my mind.

On (5), I'm not sure either set of names is the best possible, and I'm certainly not stuck on my own proposed names.

I'm not really bothered either way on this front, although 'Data' is much more likely to clash with existing code.

Regards,
Maciej

Something worth bearing in mind is that Binary/B is implemented in 2 or 3 CommonJS platforms already, but I don't think any one is particularly attached to the behaviour so long as what comes out isn't wildly different.

-ash

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-07T18:21:17Z

On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:

On 6 Nov 2009, at 19:24, Brendan Eich wrote:

On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:

Just in case some of you weren't aware, the CommonJS group has done quite a bit of work and (bikeshedding) on this topic. Here's a link to the wiki:

http://wiki.commonjs.org/wiki/Binary

If nothing else there's quite a bit of prior art collected which should inform the conversation. I know the Binary/B proposal has the implementation momentum, but I don't know exactly what the status is. I haven't been closely following the evolution of these binary specs too closely but since it seems that nearly everyone else from the group is off to jsconf.eu I figured I ought to toss this out there.

Thanks, I had forgotten about commonjs.org, having once paid better attention.

Kris did a good job with Binary/B (although I do not see the point of the .get method additions) -- I didn't look at the other proposals yet.

/be

Binary/B feels largely right, but it has a few too many methods from Array simply because Array had them for my taste, specifically things like sort, reduce, shift, unshift etc.

Conceptually: why would you want to sort an array of bytes? There are certainly classes of operations that I think should just be done via b.toArray().X rather than directly on the blob.

As a community (CommonJS) we'd be more than happy to go forward with a binary spec that came from (or at least has the blessing of) the ES groups

Binary/B is the closest of the three proposals to mine, in that it has both mutable and immutable binary data containers. Here are a few key differences:

(1) Binary/B does not have a cheap way to convert from the immutable representation (ByteString) to the mutable representation (ByteArray)

(2) In Binary/B, Array-like index access to ByteString gives back one-byte ByteStrings instead of bytes, likely an over-literal copying of String

(3) There are some seemingly needless differences in the interfaces to ByteString and ByteArray that follow from modeling on String and Array

(4) Binary/B has many more operations available in the base proposal (including charset transcoding and a generous selection of String and Array methods)

(5) Different names - Data/DataBuilder vs. ByteString/ByteArray

My initial impression is that (1), (2) and (3) are all points on which my proposal is better. On (1): cheap conversion from mutable to immutable (DataBuilder.prototype.release() in my proposal) lets binary data objects be built up with a convenient mutation-based idiom, but then passed around as immutable objects thereafter. On (2): I don't think a one-byte ByteString is ever useful, indexing to get the byte value would be much more helpful. On (3), I think it's good for the mutable interface to be a strict superset of the the immutable interface.

(4) and (5) are all points where perhaps neither proposal is at the optimum yet. On (4), I suspect the sweet spot is somewhere between my spartan set of built-in operations and the very generous set in Binary/B. On (5), I'm not sure either set of names is the best possible, and I'm certainly not stuck on my own proposed names.

Regards,

Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Presentation on modules

2009-11-07T11:27:19Z

On Sat, Nov 7, 2009 at 11:10 AM, Brendan Eich <brendan@...> wrote:
> The alternative for Harmony is a syntactic special form, an import directive
> for example, that can be analyzed when the program is parsed ...

+1. In Caja, we were loath to introduce new syntax _per se_, and we
are already compiling, so ours is a bit of a special case. Were there
some standard syntax the semantics of which we could implement, our
lives would be far easier.

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Presentation on modules

2009-11-07T11:10:21Z

So (as was clarified at the meeting) the Caja work is quite informative, but we are not looking at any Harmony module system that requires ahead-of-time code analysis and transformation before code reaches the browser.

The alternative for Harmony is a syntactic special form, an import directive for example, that can be analyzed when the program is parsed (not executed), so the implementation can preload all dependencies before execution to avoid blocking on an import (or a later data dependency), or else an awkward non-blocking import to preserve JS's run-to-completion execution model.

Async (non-blocking) import functionality (a runtime API) is good too but it should not be the only way, or the common way.

There's more to say about modules but I'll let others speak up.

/be

On Nov 7, 2009, at 9:03 AM, ihab.awad@... wrote:

On Sat, Nov 7, 2009 at 8:34 AM, Ash Berlin <ash_js@...> wrote:
Slide 10 says "Sync, arg must be a string literal". 1) why a string
*literal*, ...

It's the simplest form of statically determinable identifier. We could
say, "arg must be an expression that statically evaluates to a
string", like:

'f' + 'oo'

but we chose the simplest interpretation.

Essentially, we are making 'load' a special form.

... and 2) how can that be enforced?

The Caja system is a compiler. :)

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Presentation on modules

2009-11-07T09:03:58Z

On Sat, Nov 7, 2009 at 8:34 AM, Ash Berlin <ash_js@...> wrote:
> Slide 10 says "Sync, arg must be a string literal". 1) why a string
> *literal*, ...

It's the simplest form of statically determinable identifier. We could
say, "arg must be an expression that statically evaluates to a
string", like:

'f' + 'oo'

but we chose the simplest interpretation.

Essentially, we are making 'load' a special form.

> ... and 2) how can that be enforced?

The Caja system is a compiler. :)

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Presentation on modules

2009-11-07T08:34:47Z

On 7 Nov 2009, at 16:28, ihab.awad@... wrote:

> Hi folks,
>
> Here is a link to the presentation on modules I gave during the TC39
> meeting in Santa Clara, CA yesterday.
>
> http://sites.google.com/site/ihabawad/Home/es5Modules-2009-11-06.pdf
>
> Cheers and regards,
>
> Ihab

Slide 10 says "Sync, arg must be a string literal". 1) why a string
*literal*, and 2) how can that be enforced?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Presentation on modules

2009-11-07T08:28:32Z

Hi folks,

Here is a link to the presentation on modules I gave during the TC39
meeting in Santa Clara, CA yesterday.

http://sites.google.com/site/ihabawad/Home/es5Modules-2009-11-06.pdf

Cheers and regards,

Ihab

--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-07T05:39:35Z

On 6 Nov 2009, at 19:24, Brendan Eich wrote:

On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:

Just in case some of you weren't aware, the CommonJS group has done quite a bit of work and (bikeshedding) on this topic. Here's a link to the wiki:

http://wiki.commonjs.org/wiki/Binary

If nothing else there's quite a bit of prior art collected which should inform the conversation. I know the Binary/B proposal has the implementation momentum, but I don't know exactly what the status is. I haven't been closely following the evolution of these binary specs too closely but since it seems that nearly everyone else from the group is off to jsconf.eu I figured I ought to toss this out there.

Thanks, I had forgotten about commonjs.org, having once paid better attention.

Kris did a good job with Binary/B (although I do not see the point of the .get method additions) -- I didn't look at the other proposals yet.

/be

Binary/B feels largely right, but it has a few too many methods from Array simply because Array had them for my taste, specifically things like sort, reduce, shift, unshift etc.

Conceptually: why would you want to sort an array of bytes? There are certainly classes of operations that I think should just be done via b.toArray().X rather than directly on the blob.

As a community (CommonJS) we'd be more than happy to go forward with a binary spec that came from (or at least has the blessing of) the ES groups

-ash

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T15:39:37Z

On Nov 6, 2009, at 1:39 PM, Alex Russell wrote:

> On Nov 6, 2009, at 11:30 AM, Maciej Stachowiak wrote:
>
>>
>> On Nov 6, 2009, at 5:43 AM, P T Withington wrote:
>>
>>> On 2009-11-05, at 19:42, Maciej Stachowiak wrote:
>>>
>>>> My claim is that Data is not much like these things. I believe it
>>>> is more like String. It happens to be a sequence (of a very
>>>> specific type), but it's specialized enough to be worth treating
>>>> differently. Do people often regret that String is not an Array?
>>>
>>> Data is like an 8-bit "null encoded" String. Which makes me
>>> wonder if you really just want to extend String to allow different
>>> encodings. But I also regret String not being and Array. Others
>>> must have too, because at one point I'm sure there was a proposal
>>> to make [] on string mean charAt?
>>
>> ES5 does have bracket index access to the individual characters.
>> But it does not make String inherit from Array.prototype, or add
>> all of the Array methods. To make it more concrete, have you ever
>> wished you could use methods like map(), filter(), reduce() or
>> join() on a String?
>
> join's an oddball since it's effectively a no-op, but map() and
> filter(), absolutely.

Can you give specific use cases for these, maybe with hypothetical
code examples?

Join would not be a no-op, and indeed you can use Array.prototype.join
on a String today:

javascript:alert(Array.prototype.join.call("abcde", "123")) ==>
"a123b123c123d123e"

Not a no-op but I'm not sure it's useful.

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T13:43:37Z

On Fri, Nov 6, 2009 at 4:39 PM, Alex Russell <alex@...> wrote:
> On Nov 6, 2009, at 11:30 AM, Maciej Stachowiak wrote:
>> ES5 does have bracket index access to the individual characters. But it
>> does not make String inherit from Array.prototype, or add all of the Array
>> methods. To make it more concrete, have you ever wished you could use
>> methods like map(), filter(), reduce() or join() on a String?
>
> join's an oddball since it's effectively a no-op, but map() and filter(),
> absolutely.

I've used join too (though not with an empty separator, indeed), and
map/filter for various string pack and encode operations, but I don't
think that I would mind too much having to say

Array.join(strOrDataThing, "\n");

instead of

strOrData.filter(function (v) { return v.charCodeAt(0) < 128; });

Mike
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T13:39:06Z

On Nov 6, 2009, at 11:30 AM, Maciej Stachowiak wrote:

>
> On Nov 6, 2009, at 5:43 AM, P T Withington wrote:
>
>> On 2009-11-05, at 19:42, Maciej Stachowiak wrote:
>>
>>> My claim is that Data is not much like these things. I believe it
>>> is more like String. It happens to be a sequence (of a very
>>> specific type), but it's specialized enough to be worth treating
>>> differently. Do people often regret that String is not an Array?
>>
>> Data is like an 8-bit "null encoded" String. Which makes me wonder
>> if you really just want to extend String to allow different
>> encodings. But I also regret String not being and Array. Others
>> must have too, because at one point I'm sure there was a proposal
>> to make [] on string mean charAt?
>
> ES5 does have bracket index access to the individual characters. But
> it does not make String inherit from Array.prototype, or add all of
> the Array methods. To make it more concrete, have you ever wished
> you could use methods like map(), filter(), reduce() or join() on a
> String?

join's an oddball since it's effectively a no-op, but map() and
filter(), absolutely.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T11:51:23Z

On Nov 5, 2009, at 11:03 PM, David-Sarah Hopwood wrote:

> Oliver Hunt wrote:
>> On Nov 5, 2009, at 10:14 PM, David-Sarah Hopwood wrote:
>>> Oliver Hunt wrote:
>>>> I disagree here -- i believe mutable vs. immutable data is
>>>> different
>>>> from unfrozen and frozen objects [...]
>>>
>>> Why? What would the hypothetical Data.prototype.freeze do that
>>> would be
>>> different to applying Object.freeze to a Data object?
>>>
>>>> (though i agree that the function names
>>>> freeze and frozen are just asking for problems in conjunction
>>>> with ES5
>>>> :D ). There are plenty of times where I would want to provide
>>>> immutable
>>>> data (the UA sharing content, etc), but i may still want to
>>>> modify the
>>>> object itself.
>>>
>>> Oh, you mean that you want *read-only* Data objects backed by a
>>> mutable
>>> array. That is not the same thing as an immutable (or "frozen") Data
>>> object.
>>
>> No, the issue here is that Charles has conflated object freezing with
>> immutable data,
>
> That isn't conflation; they're the same.
>
>> frozen objects and immutable data are not the same thing
>
> You are mistaken. This is a case where terminology across languages is
> quite consistent, and is as I've described it. "Frozen" means
> exactly the
> same thing as "immutable", and implies that the state of the object
> will
> never be observed to change [*]. An object is "read-only" if there
> is no
> means to directly change its state via a reference to it, which does
> not
> necessarily imply that its state cannot be observed to change.
>
>> -- for instance in the DOM I cannot set indices of a NodeList, but
>> the
>> NodeList does not need to be frozen.
>
> NodeList objects are read-only.

This is an artifact of the way they can be created today (no exposed
ctor for them, no exposed prototype, only alien functions can generate
them, etc.). It should not be held up as a desireable design point or
a counter to something else. Mutable NodeList's which implement Array
semantics and mutability would be extremely useful.

Regards

> [*] It is ambiguous whether indirectly referenced state can change; if
> it is important that it cannot, say "deep-frozen" or "deeply
> immutable".
>
> --
> David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@...
> https://mail.mozilla.org/listinfo/es-discuss

--
Alex Russell
slightlyoff@...
alex@... BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[] on String [Was: Binary data (ByteArray/ByteVector) proposal on public-script-coord]

2009-11-06T11:35:34Z

On 2009-11-06, at 13:47, Brendan Eich wrote:

> On Nov 6, 2009, at 5:43 AM, P T Withington wrote:

[...]

>> But I also regret String not being and Array.
>
> I agree with Maciej that having mutating methods be no-ops or
> throwers strongly suggests we not mix Array and String directly.
> Being able to apply non-mutating Array methods to string (primitive,
> even) arguments is ok. Splitting a string into an Array and
> mutating, then joining -- very ok. But I don't see why you want
> String to *be* (is-a) an Array.

It must be my Lisp/Dylan upbringing bleeding through: http://bit.ly/4DEIjL

>> Others must have too, because at one point I'm sure there was a
>> proposal to make [] on string mean charAt?
>
> David Flanagan beat me to it: in ES5 and most browsers.

And I thanked him privately. I thought it was, but failed to make the
conceptual leap from [] to [[GetOwnProperty]] when searching in the
spec.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T11:30:26Z

On Nov 6, 2009, at 5:43 AM, P T Withington wrote:

> On 2009-11-05, at 19:42, Maciej Stachowiak wrote:
>
>> My claim is that Data is not much like these things. I believe it
>> is more like String. It happens to be a sequence (of a very
>> specific type), but it's specialized enough to be worth treating
>> differently. Do people often regret that String is not an Array?
>
> Data is like an 8-bit "null encoded" String. Which makes me wonder
> if you really just want to extend String to allow different
> encodings. But I also regret String not being and Array. Others
> must have too, because at one point I'm sure there was a proposal to
> make [] on string mean charAt?

ES5 does have bracket index access to the individual characters. But
it does not make String inherit from Array.prototype, or add all of
the Array methods. To make it more concrete, have you ever wished you
could use methods like map(), filter(), reduce() or join() on a String?

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-06T11:24:39Z

On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:

Just in case some of you weren't aware, the CommonJS group has done quite a bit of work and (bikeshedding) on this topic. Here's a link to the wiki:

http://wiki.commonjs.org/wiki/Binary

If nothing else there's quite a bit of prior art collected which should inform the conversation. I know the Binary/B proposal has the implementation momentum, but I don't know exactly what the status is. I haven't been closely following the evolution of these binary specs too closely but since it seems that nearly everyone else from the group is off to jsconf.eu I figured I ought to toss this out there.

Thanks, I had forgotten about commonjs.org, having once paid better attention.

Kris did a good job with Binary/B (although I do not see the point of the .get method additions) -- I didn't look at the other proposals yet.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T10:47:58Z

On Nov 6, 2009, at 5:43 AM, P T Withington wrote:

> On 2009-11-05, at 19:42, Maciej Stachowiak wrote:
>
>> My claim is that Data is not much like these things. I believe it
>> is more like String. It happens to be a sequence (of a very
>> specific type), but it's specialized enough to be worth treating
>> differently. Do people often regret that String is not an Array?
>
> Data is like an 8-bit "null encoded" String. Which makes me wonder
> if you really just want to extend String to allow different encodings.

Not for the Data use-cases.

Strings are used for binary data, which is tying our hands in
supporting UTF-16 properly. Separate issue but we should not
complicate String further IMHO.

> But I also regret String not being and Array.

I agree with Maciej that having mutating methods be no-ops or throwers
strongly suggests we not mix Array and String directly. Being able to
apply non-mutating Array methods to string (primitive, even) arguments
is ok. Splitting a string into an Array and mutating, then joining --
very ok. But I don't see why you want String to *be* (is-a) an Array.

> Others must have too, because at one point I'm sure there was a
> proposal to make [] on string mean charAt?

David Flanagan beat me to it: in ES5 and most browsers.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-06T10:44:37Z

Just in case some of you weren't aware, the CommonJS group has done quite a bit of work and (bikeshedding) on this topic. Here's a link to the wiki:

http://wiki.commonjs.org/wiki/Binary

If nothing else there's quite a bit of prior art collected which should inform the conversation. I know the Binary/B proposal has the implementation momentum, but I don't know exactly what the status is. I haven't been closely following the evolution of these binary specs too closely but since it seems that nearly everyone else from the group is off to jsconf.eu I figured I ought to toss this out there.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-06T10:21:07Z

On Nov 6, 2009, at 9:18 AM, Maciej Stachowiak wrote:

> On Nov 6, 2009, at 8:26 AM, Brendan Eich wrote:
>
> Indeed, I'd rather not propose APIs like that in the initial version
> (though I think eventually we may want a way to copy sequences of
> 16-, 32-bit or 64-bit values swapping from network byte order to
> host byte order or vice versa to make it practical to interpret
> popular binary formats.

Could be -- I agree we should defer.

> However, I think a common use case for binary data is to pass it
> around for point A to point B, without unpacking the internals at
> all, just as for strings. For example, you may read a file in binary
> form, pass the binary data off to a Worker, and then have the Worker
> upload it to a server. This is part of why I leaned towards a name
> that does not overly emphasize the byte sequence nature.

Yet the minimal API will give byte-element access, not variable-length
bit string or any other such access. Concrete beats abstract every
time in this level of discourse, in my experience.

>> Therefore I think a concrete name such as ByteVector or ByteArray
>> is better, all else equal.
>>
>> Moreover a name such as ByteVector is much easier to inject as a
>> global property. No hits for the obvious function and var forms of
>> it, one hit for ByteArray:
>>
>> http://www.google.com/codesearch?hl=en&lr=&q=%22function+ByteArray%28%22+lang%3Ajavascript&sbtn=Search
>
> Some other possible names (based in part on some other binary data
> proposals that I've seen):
>
> BinaryData
> BinData
> ByteString

These look free of conflicts from some quick codesearch'ing --
ByteString is good, better than ByteVector if we do not allow bytes to
be mutated.

> Binary

Existing uses:

http://www.google.com/codesearch?hl=en&lr=&q=%22function+Binary%28%22+lang%3Ajavascript&sbtn=Search

If any of these involve detection, we probably can't use Binary. I did
not look further, but suggest we eliminate candidate names that are
already in use according to Google codesearch.

> Blob

A few hits:

http://www.google.com/codesearch?hl=en&lr=&q=%22function+Blob%28%22+lang%3Ajavascript&sbtn=Search

/be
>
> Good topic for in-person discussion maybe?
>
> Regards,
> Maciej
>

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T10:00:13Z

P T Withington wrote:
> I also regret String not being and Array. Others must have too, because
> at one point I'm sure there was a proposal to make [] on string mean
> charAt?

This is part of ES5. See 15.5.5.2 in the spec.

David Flanagan

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T09:57:53Z

> I think the disadvantage of this design is that it puts all the
> mutation methods on immutable instances, where they are serve no
> purpose other than to throw when called. I think it is cleaner
> design for the immutable interface to lack mutation methods, rather
> than have mutation methods that always fail. I think designs where
> part of the normal workflow puts an object in a state where some
> methods always throw is poor OO design.

Well, let me argue this for a second...

Well designed systems often have objects with an internal state.
Features become available or unavailable on that object based on the
state. If you try to use a feature while the object is in the wrong
state, the object should throw an error. This is good API. It makes
it clear to the developer when they try to use the object in the wrong
way.

The API I'm arguing for envisions the Data object having some internal
state [i.e. isEditable] and a part of the API is available or not
depending on that state.

Additionally, JavaScript often uses the duck-typing pattern [i.e.
ignore the "inheritance" of an object and just check its capabilities
before acting on it]. This pattern vastly simplifies JS code as you
don't have to shuffle references around so often and can reduce memory
allocs.

That said, I will acknowledge there are many cases where methods that
throw are often indicative of bad OO design. I see this mostly in C++
and Java where devs define abstract base classes with lots of methods
that do nothing but throw. This is the opposite of what we want.
It's ugly and leads to code bloat.

In this case though, I would argue that a few if() statements at the
front of a primitive or two would actually reduce the amount of code
in regular running applications and means you only need to implement
one object.

>
> It's true that ECMAScript has not historically had mutable/immutable
> pairs of types, but this is a common pattern in other languages,
> such as Objective-C (NSString vs. NSMutableString), Java (String vs.
> StringBuilder), various recent Lisp dialects (where there are often
> both mutable and immutable lists) and arguably event C++ (const
> string and string expose different sets of method).

Most of the examples you give here, are statically-types [to various
degrees] class-based languages where inheritance chains are integral
to the design. This is not the case with JavaScript.

The two-class pattern is more important in those cases than it is here.

> That being said, I can see how there is some value to aligning with
> the evolving ECMAScript pattern. Personally I think of Object.freeze
> as a tool for building new types that are meant to be immutable, or
> for exporting partially restricted facade interfaces, not as
> something one should be doing to random objects in the course of
> normal programming.

Allow me to withdraw my previous suggestion of freeze(). It's not the
right tool for this job. The general pattern though is well
established for freeze(), seal() and extensible. I think it would
work well here too.

-Charles

PS. I'm happy to have data object support at all; this isn't really
critical to the feature IMO just an argument about which API would be
most useful to developers. I think both proposed models would be
acceptable.

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T09:34:10Z

On Nov 6, 2009, at 7:13 AM, Mike Shaver wrote:

> On Fri, Nov 6, 2009 at 9:31 AM, Breton Slivka <zen@...>
> wrote:
>> I think the C language has
>> possibly biased us into thinking of data as a sequence of 8-bit
>> bytes,
>> when that is just what happened to be convenient for C.
>
> For types called ByteArray and ByteVector, I think a byte orientation
> is appropriate. Doing things other than bytes brings endianness into
> play (ask the WebGL guys, if you know any)

At some point, if we want to make it easy and efficient for ECMAScript
to do something like decode a GIF, we may want to provide facilities
for converting between host and network byte order. My recommendation
would be to leave that out of the v1 API though.

>
>> My question is (since nobody seems to have brought it up yet) is how
>> does this proposal fit into the html5 canvas data api? (not the data
>> URI api).
>
> I would expect that there would be some harmonization desired there,
> but:
>
>> If you call canvascontext.getImageData(0,0,width,height), you get an
>> object with some mutable properties, and a data property holding what
>> looks like an array of numbers between 0 and 255. The data property
>> supposedly has an efficient implementation.
>
> Using that data property may be more efficient than using an Array,
> but that depends a bunch on the implementation choices for the JS
> engine and Canvas implementation.
>
> It was also proposed, though I don't know if it is generally accepted,
> that the Canvas Data object clamp its values to 255 on set, so if
> people feel that's a necessary behaviour (I personally don't, but my
> opinion carries less than the mean weight in these discussions) then
> ByteArray might not be suitable.
>
> The Canvas Data object is also sort of half-mutable: you can change
> the values of the data elements, but can't change the size of the
> "array". That could turn out to be a useful property for optimized
> access to it, since you can amortize length checks quite well.

CanvasPixelArray seems close enough to a mutable general-purpose
binary data container that maybe it's worth considering whether to
specifically serve this case (fixed length, mutable contents) at the
ECMAScript level. It would then likely be possible to change
CanvasPixelArray to inherit from a general-purpose binary data
container without breaking compat.

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-06T09:18:38Z

On Nov 6, 2009, at 8:26 AM, Brendan Eich wrote:

> On Nov 6, 2009, at 1:34 AM, Maciej Stachowiak wrote:
>
>> = Issues for the binary data API:
>>
>> Name (potential bikeshed):
>> ByteArray
>> ByteVector
>> BinaryData
>> Data
>
> This isn't just rank bikeshedding:
>
> 1. Data is so common a name that we can't confidently inject it into
> the global object without fear of breaking something. JSON, in spite
> of json2.js precedent, was implemented incompatibly and object-
> detected insufficiently, although this was corrected by the
> implementors (Facebook folks, much appreciated). Google codesearch
> results:
>
> http://www.google.com/codesearch?as_q=%22function+Data%28%22&btnG=Search+Code&hl=en&as_lang=javascript&as_case=y
> http://www.google.com/codesearch?as_q=%22var+Data;%22&btnG=Search+Code&hl=en&as_lang=javascript&as_case=y
> http://www.google.com/codesearch?as_q=%22var+Data%20=%22&btnG=Search+Code&hl=en&as_lang=javascript&as_case=y
>
> 2. Data is annoyingly close to Date.
>
> 3. Data is technically plural, and usage sometimes treats it as
> plural (ok, this is almost bikeshedding, I admit). For a String
> analogue this is awkward.

You're right that there are some objective factors which may rule out
certain names, in addition to subjective taste concerns. I tried not
to think too hard about the name in making the original proposal,
since I figured there would be a range of opinion. Your stated reasons
against Data seem decent.

>
>
>> I like "Data" and similar names. Objective-C has NSData as a
>> distinct type for chunks of binary data - it's not treated as a
>> type of array. I think this makes sense. Often the fact that a
>> chunk of binary data can be treated as an octet sequence is
>> incidental.
>
> It's not incidental unless you provide wider-than-byte element
> access and address byte order. Let's not, in the interest of serving
> API simplicity and common octet-sequence use-cases first and only
> (if we can hold this line).

Indeed, I'd rather not propose APIs like that in the initial version
(though I think eventually we may want a way to copy sequences of 16-,
32-bit or 64-bit values swapping from network byte order to host byte
order or vice versa to make it practical to interpret popular binary
formats.

However, I think a common use case for binary data is to pass it
around for point A to point B, without unpacking the internals at all,
just as for strings. For example, you may read a file in binary form,
pass the binary data off to a Worker, and then have the Worker upload
it to a server. This is part of why I leaned towards a name that does
not overly emphasize the byte sequence nature.

>
> Therefore I think a concrete name such as ByteVector or ByteArray is
> better, all else equal.
>
> Moreover a name such as ByteVector is much easier to inject as a
> global property. No hits for the obvious function and var forms of
> it, one hit for ByteArray:
>
> http://www.google.com/codesearch?hl=en&lr=&q=%22function+ByteArray%28%22+lang%3Ajavascript&sbtn=Search

Some other possible names (based in part on some other binary data
proposals that I've seen):

BinaryData
BinData
ByteString
Binary
Blob

Good topic for in-person discussion maybe?

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-06T08:26:45Z

On Nov 6, 2009, at 1:34 AM, Maciej Stachowiak wrote:

> = Issues for the binary data API:
>
> Name (potential bikeshed):
> ByteArray
> ByteVector
> BinaryData
> Data

This isn't just rank bikeshedding:

1. Data is so common a name that we can't confidently inject it into
the global object without fear of breaking something. JSON, in spite
of json2.js precedent, was implemented incompatibly and object-
detected insufficiently, although this was corrected by the
implementors (Facebook folks, much appreciated). Google codesearch
results:

http://www.google.com/codesearch?as_q=%22function+Data%28%22&btnG=Search+Code&hl=en&as_lang=javascript&as_case=y
http://www.google.com/codesearch?as_q=%22var+Data;%22&btnG=Search+Code&hl=en&as_lang=javascript&as_case=y
http://www.google.com/codesearch?as_q=%22var+Data%20=%22&btnG=Search+Code&hl=en&as_lang=javascript&as_case=y

2. Data is annoyingly close to Date.

3. Data is technically plural, and usage sometimes treats it as plural
(ok, this is almost bikeshedding, I admit). For a String analogue this
is awkward.

> I like "Data" and similar names. Objective-C has NSData as a
> distinct type for chunks of binary data - it's not treated as a type
> of array. I think this makes sense. Often the fact that a chunk of
> binary data can be treated as an octet sequence is incidental.

It's not incidental unless you provide wider-than-byte element access
and address byte order. Let's not, in the interest of serving API
simplicity and common octet-sequence use-cases first and only (if we
can hold this line).

Therefore I think a concrete name such as ByteVector or ByteArray is
better, all else equal.

Moreover a name such as ByteVector is much easier to inject as a
global property. No hits for the obvious function and var forms of it,
one hit for ByteArray:

http://www.google.com/codesearch?hl=en&lr=&q=%22function+ByteArray%28%22+lang%3Ajavascript&sbtn=Search

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T07:13:27Z

On Fri, Nov 6, 2009 at 9:31 AM, Breton Slivka <zen@...> wrote:
>I think the C language has
> possibly biased us into thinking of data as a sequence of 8-bit bytes,
> when that is just what happened to be convenient for C.

For types called ByteArray and ByteVector, I think a byte orientation
is appropriate. Doing things other than bytes brings endianness into
play (ask the WebGL guys, if you know any)

> My question is (since nobody seems to have brought it up yet) is how
> does this proposal fit into the html5 canvas data api? (not the data
> URI api).

I would expect that there would be some harmonization desired there, but:

> If you call canvascontext.getImageData(0,0,width,height), you get an
> object with some mutable properties, and a data property holding what
> looks like an array of numbers between 0 and 255. The data property
> supposedly has an efficient implementation.

Using that data property may be more efficient than using an Array,
but that depends a bunch on the implementation choices for the JS
engine and Canvas implementation.

It was also proposed, though I don't know if it is generally accepted,
that the Canvas Data object clamp its values to 255 on set, so if
people feel that's a necessary behaviour (I personally don't, but my
opinion carries less than the mean weight in these discussions) then
ByteArray might not be suitable.

The Canvas Data object is also sort of half-mutable: you can change
the values of the data elements, but can't change the size of the
"array". That could turn out to be a useful property for optimized
access to it, since you can amortize length checks quite well.

Mike
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T06:31:50Z

On Sat, Nov 7, 2009 at 12:43 AM, P T Withington <ptw@...> wrote:

> On 2009-11-05, at 19:42, Maciej Stachowiak wrote:
>
>> My claim is that Data is not much like these things. I believe it is more
>> like String. It happens to be a sequence (of a very specific type), but it's
>> specialized enough to be worth treating differently. Do people often regret
>> that String is not an Array?
>
> Data is like an 8-bit "null encoded" String. Which makes me wonder if you
> really just want to extend String to allow different encodings. But I also
> regret String not being and Array. Others must have too, because at one
> point I'm sure there was a proposal to make [] on string mean charAt?

Sorry to get philisophical here, but data is anything you happen to
interpret it as, it's not any particular thing. It could be an image,
it could be a string, it could be machine instructions, it could be a
sequence of octets, it could be hexidecimal. Asking what data is like
is a little bit useless. The question to ask is what kind of api makes
the most sense for conveniently manipulating data on a low level, and
in a way that isn't unfeasably slow, or awkward. What kind of api will
allow the programmer to efficiently interpret that data as things
other than what are built into the browser. I think the C language has
possibly biased us into thinking of data as a sequence of 8-bit bytes,
when that is just what happened to be convenient for C. There are
other ways to think about data: even within C you can define a struct,
point it at some area of memory, and the struct magically interprets
that data as an object like thing. Or you can even scanf. These
concepts do not depend on a byte stream, or "string" interpretation of
data.

By the way, it might not be standard, but "hello world"[0] returns "h"
on anything but IE, so far as I've tried.

My question is (since nobody seems to have brought it up yet) is how
does this proposal fit into the html5 canvas data api? (not the data
URI api).

If you call canvascontext.getImageData(0,0,width,height), you get an
object with some mutable properties, and a data property holding what
looks like an array of numbers between 0 and 255. The data property
supposedly has an efficient implementation. There is also a
putImageData function which accepts a data object, but not an array
object, and a constructor, context.createImageData(width,height);

This is already in browsers, and is in the process of being
standardised in html5. I just wonder what happens if ecmascript then
adds its own data object, how would it interact with the canvas data
apis?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T05:43:56Z

On 2009-11-05, at 19:42, Maciej Stachowiak wrote:

> My claim is that Data is not much like these things. I believe it is
> more like String. It happens to be a sequence (of a very specific
> type), but it's specialized enough to be worth treating differently.
> Do people often regret that String is not an Array?

Data is like an 8-bit "null encoded" String. Which makes me wonder if
you really just want to extend String to allow different encodings.
But I also regret String not being and Array. Others must have too,
because at one point I'm sure there was a proposal to make [] on
string mean charAt?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary Data - possible topic for joint session

2009-11-06T01:34:16Z

+ es-discuss (since posting there seems to have piqued more interest)

From reading over other proposals for binary data, I should mention
the following operations that seem to be of interest to some
communities but are not directly provided in this proposal (with ones
I think are most appropriate for v1 first):

- Subrange/subdata/substring (get a Data that's a range from another's
buffer - perhaps this could be optimized not to copy)
- Concatenation (specifically the ability to concatenate two immutable
Data objects and get a new one back without having to go through the
mutable type).
- Ability to convert to/from strings (with some hardcoded encoding or
choice of encoding)
- Some or all of the operations of Array
- Base64 encode/decode
- Methods to compute various cryptographic hashes
- Find first or last occurrence of a byte or byte sequence (from a
given offset)
- Split on a byte or byte sequence

I think it is possible to implement all of these with the primitives
in my proposal, and in many cases the utility seems dubious (do you
really want to map() or reduce() binary data one byte at a time?).
Thus, I lean towards keeping the API relatively minimal, at least for
starters.

Regards,
Maciej

On Nov 4, 2009, at 4:26 PM, Maciej Stachowiak wrote:

>
> Many APIs being developed for the Web platform would benefit from a
> good way to store binary data. It would be useful for this to be
> specified as part of the ECMAScript language, but it's also
> plausible to make this a W3C spec that's only intended for use with
> Web platform APIs. Here is an overview of some of the APIs that
> could use such a data type, some notes on requirements and design
> alternatives, and a strawman proposal.
>
> = If there's time, I'd like to discuss this at the joint TC-39/HTML
> WG/Web Apps WG session.
>
> Some APIs that could use this:
>
> XMLHttpRequest v2 - to receive and send binary data
> WebSocket - to receive and send binary packets
> File API - to read binary files
> Canvas - to get image data in the binary form of an image format
> (avoiding inefficiency of data: URLs)
> various storage APIs - to store and retrieve binary data (in
> combination with other APIs)
> postMessage - to send binary data cross-window and cross-thread
> (to Workers) efficiently
>
> I suspect there's more I am not thinking of. A convenient and
> efficient way to represent binary data could also be useful for pure
> ES programs.
>
>
> = Current de facto ways for Web apps to deal with binary data:
>
> Array of numbers with one byte per entry
> String with one byte stored per UTF-16 code unit
> String with two bytes stored per UTF-16 code unit
>
> I hope it is obvious why these approaches are not great so I won't
> go into detail.
>
>
> = Issues for the binary data API:
>
> Name (potential bikeshed):
> ByteArray
> ByteVector
> BinaryData
> Data
>
> I like "Data" and similar names. Objective-C has NSData as a
> distinct type for chunks of binary data - it's not treated as a type
> of array. I think this makes sense. Often the fact that a chunk of
> binary data can be treated as an octet sequence is incidental.
>
> == Mutable or Immutable (or both?)
>
> Immutable has a number of advantages:
> - Can share backing store with chunks of binary data that the UA
> already holds (e.g. in the network cache) without requiring copy-on-
> write
> - Can be passed cross-thread without copying, and without
> breaking shared-nothing semantics
> - Has the right semantics for passing cross-window (can make a
> copy in cross-process case, but avoid it in same-process case; or
> use shared memory in cross-process case without worrying about
> locking or races)
> - Follows the approach of ES strings, which are immutable
>
> But there's some significant disadvantages too:
> - What if you actually want to mutate some piece of binary data
> you got before passing it along? How to do this efficiently?
> - What if you want to build a new binary data item from scratch?
>
> With strings, the answer to both building and mutation is to extract
> pieces and build a new string by concatenation. But that's probably
> not efficient or convenient enough for the binary data case.
>
> Possible solution: provide immutable Data, but have a DataBuilder
> class to allow creating new data items or mutating copies of
> existing ones, which can then give a final immutable product.
>
>
> == What Operations?
>
> Operation set could be a full set of array-like operations,
> absolutely minimal (just accessors for individual bytes), or middle
> ground (byte-level accessors plus a few bulk operations like the
> equivalent of memcpy). I like the middle ground.
>
> == Rough API Proposal
>
> Here's a sketch of a binary data API that's immutable (with mutable
> builder class), and provides a middle-ground set of operations. The
> basic idea is that binary data should be considered a first-class
> datatype in its own right, just as strings are, rather than being
> thought of as a kind of array.
>
> Data -- global constructor
> When called or invoked as a constructor with a number parameter,
> return a new Data object of the specified size, filled with all zero
> bytes.
>
> Data.prototype -- the initial Data prototype
>
> Data.prototype.builderCopy()
>
> When called with a Data instance as the this parameter, return a
> new DataBuilder object starting with the same size and a copy of the
> bytes in this Data object.
>
> Data instance properties:
>
> length - size of the Data object - read-only
> index properties - individual bytes of the Data (similar to array
> access) - read-only
>
> DataBuilder -- global constructor
> When called or invoked as a constructor with a number parameter,
> return a new DataBuilder object of the specified size, filled with
> all zero bytes.
>
> DataBuilder.prototype.builderCopy()
>
> When called with a DataBuilder instance as the this parameter,
> return a new DataBuilder object starting with the same size and a
> copy of the bytes in this Data object.
>
> DataBuilder.prototype.copyRange(dstStart, srcObject, srcStart, srcEnd)
>
> When called with a DataBuilder instance as the this parameter,
> copy bytes from srcObject starting at offset srcStart up to offset
> srcEnd. srcObject can be a Data or a DataBuilder, and can be the
> same as the "this" object. Overlapping ranges are guaranteed to be
> copied correctly. dstStart is the offset in this DataBuilder at
> which to provide writing.
>
> DataBuilder.prototype.fill(byte, dstStart, dstEnd)
>
> Fill with "byte" from dstStart to dstEnd.
>
> DataBuilder.prototype release()
>
> Return a Data object of the same size and containing the same
> bytes as this DataBuilder, and at the same time reset this
> DataBuilder to 0 length. This is so that the new Data object can
> adopt the buffer of this DataBuilder without copying, which is what
> is commonly desired.
>
> DataBuilder instance properties:
>
> length - size of the Data object - read-write
> index properties - individual bytes of the DataBuilder (similar
> to array access) - read-write
>
>
> Rationale:
>
> - copyRange() and fill() are the only higher-level operations
> provided, because they can be implemented much more efficiently for
> large ranges in native code than in ECMAScript.
>
> - Data would be returned and taken by all Web APIs, its
> immutability allows binary data to be passed around without copying.
>
> - DataBuilder allows creation and mutation while minimizing copies
> and letting most of a system maintain the benefits of immutability.
>
> - DataBuilder.prototype.release() is specifically designed to let
> a program use mutation to build up a chunk of binary data, then pass
> it off to code that should not mutate it or across boundaries with
> shared-nothing semantics (like Workers), without requiring a copy
> after initially building.
>
> Sorry that this is so sketchy, but I thought this would make a good
> starting point for discussion.
>
> Regards,
> Maciej
>
>
>
>
>
>
>
>
>

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T01:24:06Z

On Nov 5, 2009, at 5:14 PM, Charles Jolley wrote:

> I hadn't thought about freeze affecting all other values on the
> object. I agree that is not desirable.
>
> Still, having separate object types for mutable and immutable
> objects introduces a new pattern to JS. Why not follow the pattern
> used for freeze(), seal() and preventExtension()? Here's another
> alternative as an example:
>
> Data.preventEdits(foo);
> - makes editable data not editable
>
> Data.isEditable(foo);
> - returns true if editable
>
> foo.copy();
> - returns a copy of foo, matching editable state. If foo is not
> editable, may return foo
>
> foo.editableCopy();
> - returns an editable copy of foo, regardless of editable state
>
> Incidentally this API above could be implemented using separate
> object types as you suggest by making DataBuilder an extension of
> Data. This would be an implementation detail though rather than a
> fundamental part of the API.

I don't think that would work, unless Data.preventEdits(foo) returns a
new value.

I think the disadvantage of this design is that it puts all the
mutation methods on immutable instances, where they are serve no
purpose other than to throw when called. I think it is cleaner design
for the immutable interface to lack mutation methods, rather than have
mutation methods that always fail. I think designs where part of the
normal workflow puts an object in a state where some methods always
throw is poor OO design.

It's true that ECMAScript has not historically had mutable/immutable
pairs of types, but this is a common pattern in other languages, such
as Objective-C (NSString vs. NSMutableString), Java (String vs.
StringBuilder), various recent Lisp dialects (where there are often
both mutable and immutable lists) and arguably event C++ (const string
and string expose different sets of method).

That being said, I can see how there is some value to aligning with
the evolving ECMAScript pattern. Personally I think of Object.freeze
as a tool for building new types that are meant to be immutable, or
for exporting partially restricted facade interfaces, not as something
one should be doing to random objects in the course of normal
programming.

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

2009-11-06T01:14:34Z

On Nov 5, 2009, at 11:03 PM, David-Sarah Hopwood wrote:

Oliver Hunt wrote:

-- for instance in the DOM I cannot set indices of a NodeList, but the
NodeList does not need to be frozen.

NodeList objects are read-only.

But the values they return may change over time due to factors other than manipulating the NodeList.

Regards,

Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss