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

[Maciej Stachowiak]

I pulled together a rough proposal for representing binary data in  
ECMAScript and posted it on public-script-coord. I think having this  
is important for many W3C specs, but it is probably best defined in  
ECMAScript. I'm posting a link here in case anyone is interested and  
is not on the public-script-coord mailing list yet:

http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html

Regards,
Maciej

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

[Alex Russell]

On Nov 5, 2009, at 2:48 PM, Maciej Stachowiak wrote:

>
> I pulled together a rough proposal for representing binary data in  
> ECMAScript and posted it on public-script-coord. I think having this  
> is important for many W3C specs, but it is probably best defined in  
> ECMAScript. I'm posting a link here in case anyone is interested and  
> is not on the public-script-coord mailing list yet:
>
> http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html

Looks promising! A couple of thoughts:

   * the middle-ground approach seems interesting, although having  
them not be "real" arrays feels like we're just kicking the can down  
the road WRT the large-ish number of things that could be thought of  
as arrays but which don't act like them (NodeList, arguments, etc.).
   * any thoughts on type conversions? what does this do/return?:

      var bits = new Data("...");
      var res = bits += "?";

      will strings have a toData() protocol? Should other objects be  
able to implement such a protocol? will there be a canonical byte  
format for all strings in the language?
    * given that Data are array-like things that have the property of  
being packed (like arguments), maybe we're just missing a PackedArray  
superclass in general that could help w/ the efficiency concerns  
(irrespective of mutability).
    * what do you think about a toArray() method?
    * do you envision any provision for multi-dimensional Data  
objects? E.g., <canvas> data.

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

[Charles Jolley]

This looks like a good approach.  I wonder if the Data/DataBuilder  
distinction could be handled better by using the Object.freeze()  
semantics.  Even if the browser does not support freezing in the  
general sense yet, you could borrow the ideas for data.

Probably the wrong API names, but here is the basic idea:

Data.prototype.copy()
   -> returns a mutable form of the Data object

Data.prototype.freeze() or Data.freeze(aDataObject)
   -> makes the Data object frozen if it is not frozen already

Data.prototype.frozenCopy()
   -> returns the data object but pre-frozen.  For Data object's  
already frozen can return "this"

Data.prototype.frozen - true when frozen, false otherwise.

--

Browser API's that return a data object can return pre-frozen data,  
allowing for all the sharing scenarios your outlined in your mail.

This is basically a copy of the mutable/immutable API of Cocoa, btw,  
just reversed.  (i.e. you get frozenCopy() instead of a mutableCopy())

-Charles

On Nov 5, 2009, at 2:48 PM, Maciej Stachowiak wrote:

>
> I pulled together a rough proposal for representing binary data in  
> ECMAScript and posted it on public-script-coord. I think having this  
> is important for many W3C specs, but it is probably best defined in  
> ECMAScript. I'm posting a link here in case anyone is interested and  
> is not on the public-script-coord mailing list yet:
>
> http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html
>
> Regards,
> Maciej
>
> _______________________________________________
> 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

[David-Sarah Hopwood-2]

Charles Jolley wrote:

> This looks like a good approach.  I wonder if the Data/DataBuilder
> distinction could be handled better by using the Object.freeze()
> semantics.  Even if the browser does not support freezing in the general
> sense yet, you could borrow the ideas for data.
>
> Probably the wrong API names, but here is the basic idea:
>
> Data.prototype.copy()
>   -> returns a mutable form of the Data object
>
> Data.prototype.freeze() or Data.freeze(aDataObject)
>   -> makes the Data object frozen if it is not frozen already
>
> Data.prototype.frozenCopy()
>   -> returns the data object but pre-frozen.  For Data object's already
> frozen can return "this"
>
> Data.prototype.frozen - true when frozen, false otherwise.

I don't know why we wouldn't just use Object.freeze. It is not unreasonable
to require support for the ES5 APIs as a prerequisite for the Data type.

--
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



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

[Oliver Hunt-2]

On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:

> Charles Jolley wrote:
>> This looks like a good approach.  I wonder if the Data/DataBuilder
>> distinction could be handled better by using the Object.freeze()
>> semantics.  Even if the browser does not support freezing in the  
>> general
>> sense yet, you could borrow the ideas for data.
>>
>> Probably the wrong API names, but here is the basic idea:
>>
>> Data.prototype.copy()
>>  -> returns a mutable form of the Data object
>>
>> Data.prototype.freeze() or Data.freeze(aDataObject)
>>  -> makes the Data object frozen if it is not frozen already
>>
>> Data.prototype.frozenCopy()
>>  -> returns the data object but pre-frozen.  For Data object's  
>> already
>> frozen can return "this"
>>
>> Data.prototype.frozen - true when frozen, false otherwise.
>
> I don't know why we wouldn't just use Object.freeze. It is not  
> unreasonable
> to require support for the ES5 APIs as a prerequisite for the Data  
> type.

I disagree here -- i believe mutable vs. immutable data is different  
from unfrozen and frozen objects (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.

Basically i think we're attempting to conflate the ES object with the  
data wrapped by the ES object.

--Oliver

>
> --
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>
> _______________________________________________
> 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

[Maciej Stachowiak]

Added public-script-coord since discussion is happening here.

On Nov 5, 2009, at 3:08 PM, Alex Russell wrote:

> On Nov 5, 2009, at 2:48 PM, Maciej Stachowiak wrote:
>
>>
>> I pulled together a rough proposal for representing binary data in  
>> ECMAScript and posted it on public-script-coord. I think having  
>> this is important for many W3C specs, but it is probably best  
>> defined in ECMAScript. I'm posting a link here in case anyone is  
>> interested and is not on the public-script-coord mailing list yet:
>>
>> http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html
>
> Looks promising! A couple of thoughts:
>
>  * the middle-ground approach seems interesting, although having  
> them not be "real" arrays feels like we're just kicking the can down  
> the road WRT the large-ish number of things that could be thought of  
> as arrays but which don't act like them (NodeList, arguments, etc.).

I understand the concern. Indeed, for things like NodeList or  
HTMLCollection or arguments, it's often very desirable

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? My impression is  
that this is not a common concern. That's why I imagined this design  
point.

But imagine we decided to go the other way and try to make these  
things arrays:

(a) I believe DataBuilder could be made an Array without introducing  
serious problems.
(b) I think Data could be made an array, but all the mutating methods  
of Array (which is a great deal of them) will always fail, so that  
seems like poor API design. I'd prefer to have a design where the  
immutable object lacks mutating methods entirely, rather than having  
mutating methods that always fail. That being said, just the read-only  
methods from the Array prototype could be provided.
(c) Array methods that return a new Array may be poor fits for Data/
DataBuilder - perhaps they could return a Data or DataBuilder instead  
if they are provided.

>  * any thoughts on type conversions? what does this do/return?:
>
>     var bits = new Data("...");
>     var res = bits += "?";
>
>     will strings have a toData() protocol? Should other objects be  
> able to implement such a protocol? will there be a canonical byte  
> format for all strings in the language?

Converting a String to a Data presumably involves charset encoding/
decoding. I have not made a proposal for that in my initial strawman.  
I do think charset transcoding is an extremely useful feature for many  
use cases though, especially ability to encode/decode UTF-8 and  
WinLatin1. Since you need a choice of charset encoding to meaningfully  
convert between binary data and strings, I think it's better not to  
make it implicit, but rather have explicit named methods that can take  
the encoding as a parameter. At least, that's my tentative thinking.  
Another possibility is to assume that in cases where you don't specify  
an encoding, strings are converted to/from UTF-16.

>   * given that Data are array-like things that have the property of  
> being packed (like arguments), maybe we're just missing a  
> PackedArray superclass in general that could help w/ the efficiency  
> concerns (irrespective of mutability).

I'm not sure what you mean by being packed or the similarity to  
arguments. Arguments contains arbitrary values, Data contains only  
unsigned integers in the range 0-255. Data is immutable. And with  
Data, it may not often be desirable

>   * what do you think about a toArray() method?

That can certainly be done. I am somewhat wary, because I think the  
Array version will often be much less efficient in speed and memory,  
and I believe it will rarely actually be useful. Imagine getting a raw  
binary JPEG over the wire. It's extremely unlikely you'd want to  
convert this to an Array, or call methods like filter() or map() on it.

>   * do you envision any provision for multi-dimensional Data  
> objects? E.g., <canvas> data.

The proposal here is that Data just holds raw binary data, without  
imposing structure. If you want to use it to hold image data or a  
frame buffer, then by my proposal, you have to do the indexing math  
yourself.

Regards,
Maciej



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

[Maciej Stachowiak]

Using the freeze pattern is an interesting possibility that I hadn't  
considered. Tentatively, I think having separate types for mutable and  
immutable is better than using freeze(). Here are my reasons:

- It seems like it may be useful to have an immutable Data (one that  
doesn't let you change the buffer) but which is not in other respects  
frozen.
- The immutable type would not only freeze the types, but also not  
provide functioning mutation methods. I think it is cleaner design for  
the immutable form of the object to lack mutation methods entirely,  
rather than to have neutered mutation methods that always fail or  
always throw.

That being said, I think it's an alternative worth considering.

Is there enough interest in this topic in general to spend some of the  
joint TC-39/HTML/WebApps session on it?

Regards,
Maciej

On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:

> Charles Jolley wrote:
>> This looks like a good approach.  I wonder if the Data/DataBuilder
>> distinction could be handled better by using the Object.freeze()
>> semantics.  Even if the browser does not support freezing in the  
>> general
>> sense yet, you could borrow the ideas for data.
>>
>> Probably the wrong API names, but here is the basic idea:
>>
>> Data.prototype.copy()
>>  -> returns a mutable form of the Data object
>>
>> Data.prototype.freeze() or Data.freeze(aDataObject)
>>  -> makes the Data object frozen if it is not frozen already
>>
>> Data.prototype.frozenCopy()
>>  -> returns the data object but pre-frozen.  For Data object's  
>> already
>> frozen can return "this"
>>
>> Data.prototype.frozen - true when frozen, false otherwise.
>
> I don't know why we wouldn't just use Object.freeze. It is not  
> unreasonable
> to require support for the ES5 APIs as a prerequisite for the Data  
> type.
>

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

[Charles Jolley]

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.

-Charles

On Nov 5, 2009, at 4:55 PM, Maciej Stachowiak wrote:

>
> Using the freeze pattern is an interesting possibility that I hadn't  
> considered. Tentatively, I think having separate types for mutable  
> and immutable is better than using freeze(). Here are my reasons:
>
> - It seems like it may be useful to have an immutable Data (one that  
> doesn't let you change the buffer) but which is not in other  
> respects frozen.
> - The immutable type would not only freeze the types, but also not  
> provide functioning mutation methods. I think it is cleaner design  
> for the immutable form of the object to lack mutation methods  
> entirely, rather than to have neutered mutation methods that always  
> fail or always throw.
>
> That being said, I think it's an alternative worth considering.
>
> Is there enough interest in this topic in general to spend some of  
> the joint TC-39/HTML/WebApps session on it?
>
> Regards,
> Maciej
>
> On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:
>
>> Charles Jolley wrote:
>>> This looks like a good approach.  I wonder if the Data/DataBuilder
>>> distinction could be handled better by using the Object.freeze()
>>> semantics.  Even if the browser does not support freezing in the  
>>> general
>>> sense yet, you could borrow the ideas for data.
>>>
>>> Probably the wrong API names, but here is the basic idea:
>>>
>>> Data.prototype.copy()
>>> -> returns a mutable form of the Data object
>>>
>>> Data.prototype.freeze() or Data.freeze(aDataObject)
>>> -> makes the Data object frozen if it is not frozen already
>>>
>>> Data.prototype.frozenCopy()
>>> -> returns the data object but pre-frozen.  For Data object's  
>>> already
>>> frozen can return "this"
>>>
>>> Data.prototype.frozen - true when frozen, false otherwise.
>>
>> I don't know why we wouldn't just use Object.freeze. It is not  
>> unreasonable
>> to require support for the ES5 APIs as a prerequisite for the Data  
>> type.
>>
>
> _______________________________________________
> 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

[David-Sarah Hopwood-2]

Oliver Hunt wrote:

> On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:
>> Charles Jolley wrote:
>>> This looks like a good approach.  I wonder if the Data/DataBuilder
>>> distinction could be handled better by using the Object.freeze()
>>> semantics.  Even if the browser does not support freezing in the general
>>> sense yet, you could borrow the ideas for data.
>>>
>>> Probably the wrong API names, but here is the basic idea:
>>>
>>> Data.prototype.copy()
>>>  -> returns a mutable form of the Data object
>>>
>>> Data.prototype.freeze() or Data.freeze(aDataObject)
>>>  -> makes the Data object frozen if it is not frozen already
>>>
>>> Data.prototype.frozenCopy()
>>>  -> returns the data object but pre-frozen.  For Data object's already
>>> frozen can return "this"
>>>
>>> Data.prototype.frozen - true when frozen, false otherwise.
>>
>> I don't know why we wouldn't just use Object.freeze. It is not
>> unreasonable to require support for the ES5 APIs as a prerequisite
>> for the Data type.
>
> 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.

--
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



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

[Charles Jolley]

> Why? What would the hypothetical Data.prototype.freeze do that would  
> be
> different to applying Object.freeze to a Data object?

For example, I might load an immutable JPG and then want to set:

imageData.name = "someimage.jpg";

to help me keep track of what the data is.  Freezing would prevent  
adding useful "expando" properties such as this as well as preventing  
changing the data.  This is equally non-JS-like IMO.

-Charles

>
>> (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.
>
> --
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>
> _______________________________________________
> 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

[Oliver Hunt-2]

On Nov 5, 2009, at 10:14 PM, David-Sarah Hopwood wrote:

> Oliver Hunt wrote:
>> On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:
>>> Charles Jolley wrote:
>>>> This looks like a good approach.  I wonder if the Data/DataBuilder
>>>> distinction could be handled better by using the Object.freeze()
>>>> semantics.  Even if the browser does not support freezing in the  
>>>> general
>>>> sense yet, you could borrow the ideas for data.
>>>>
>>>> Probably the wrong API names, but here is the basic idea:
>>>>
>>>> Data.prototype.copy()
>>>> -> returns a mutable form of the Data object
>>>>
>>>> Data.prototype.freeze() or Data.freeze(aDataObject)
>>>> -> makes the Data object frozen if it is not frozen already
>>>>
>>>> Data.prototype.frozenCopy()
>>>> -> returns the data object but pre-frozen.  For Data object's  
>>>> already
>>>> frozen can return "this"
>>>>
>>>> Data.prototype.frozen - true when frozen, false otherwise.
>>>
>>> I don't know why we wouldn't just use Object.freeze. It is not
>>> unreasonable to require support for the ES5 APIs as a prerequisite
>>> for the Data type.
>>
>> 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, frozen objects and immutable data are not the same  
thing -- for instance in the DOM I cannot set indices of a NodeList,  
but the NodeList does not need to be frozen.

It is perfectly reasonable to have raw data that is immutable without  
wanting the object that represents it to itself be immutable.

--Oliver

>
> --
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>
> _______________________________________________
> 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

[David-Sarah Hopwood-2]

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.


[*] 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

[David-Sarah Hopwood-2]

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.

Sorry, I understand what you meant now.

An object could of course have immutable data properties but other
properties that are mutable. But that can be achieved already using
Object.defineProperties, if it were considered useful. I don't see it
as particularly useful, given that you can achieve a similar effect
more simply by using a mutable "record" object that has an immutable
Data object as one of its properties.

Remember, we have Object.freeze regardless. Therefore, if we have
a mutable byte array, then applying Object.freeze to it yields an
immutable byte array. So adding an extra type to represent immutable
byte arrays is redundant.

--
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



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

[Brendan Eich-3]

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

>> No, the issue here is that Charles has conflated object freezing with
>> immutable data,
>
> That isn't conflation; they're the same.

Not necessarily. Counter-example: a JS String object wrapping a JS  
string primitive is mutable but its character data (the primitive  
string) is apparently immutable.

/be


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

[Maciej Stachowiak]

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

[Maciej Stachowiak]

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

[P T Withington]

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

[Breton Slivka]

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

[Mike Shaver]

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

[Maciej Stachowiak]

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