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
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
t
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 char
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
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
>> dif
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()
semantic
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
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 freez
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
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 ch
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 ha
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
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 th
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
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 h
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 pu
16 matches
Mail list logo
