On Aug 27, 2013, at 3:49 PM, David Herman wrote:
> On Aug 27, 2013, at 9:47 AM, Filip Pizlo wrote:
>
>> I do. Placing named properties on arrays makes sense. Consider a matrix
>> implemented as a Float32Array, with named properties telling you the numRows
>> and numCols. Just one example.
>
On Tue, Aug 27, 2013 at 4:14 PM, K. Gadd wrote:
> To me the compelling argument against using encapsulation instead of
> extensibility is that it breaks compatibility with existing JS code. Once
> you encapsulate an array, the encapsulated object no longer acts like an
> array and you can't use i
On Aug 27, 2013, at 3:49 PM, David Herman wrote:
> On Aug 27, 2013, at 9:47 AM, Filip Pizlo wrote:
>
>> I do. Placing named properties on arrays makes sense. Consider a matrix
>> implemented as a Float32Array, with named properties telling you the numRows
>> and numCols. Just one example.
>
To me the compelling argument against using encapsulation instead of
extensibility is that it breaks compatibility with existing JS code. Once
you encapsulate an array, the encapsulated object no longer acts like an
array and you can't use it in contexts where a normal array is expected.
The abilit
On Aug 27, 2013, at 9:47 AM, Filip Pizlo wrote:
> I do. Placing named properties on arrays makes sense. Consider a matrix
> implemented as a Float32Array, with named properties telling you the numRows
> and numCols. Just one example.
There are of course other ways to achieve this that don't i
Le 27 août 2013 à 18:48, Andrea Giammarchi a
écrit :
> let me rephrase ... I've no idea what this code does if not a syntax error
> (and for different reasons)
>
> `for (let m of re.execAll(str) {`
>
> what is `of` ... will `let` mark that variable as local ? what is returned
> and what wi
On Tue, Aug 27, 2013 at 9:35 AM, Oliver Hunt wrote:
> Existing types with magic index properties (other than Array) just drop
> numeric expandos on the floor so it's logically a no-op.
Dropping assignments silently is a bug, as it allows code to innocently
proceed on control flow paths that ass
On Aug 27, 2013, at 9:43 AM, Allen Wirfs-Brock wrote:
>
> On Aug 27, 2013, at 9:26 AM, Domenic Denicola wrote:
>
>> I am not aware of all the nuances of the discussion, but as a developer I
>> would find the behavior for numeric expandos confusing. For a typed array of
>> length 1024, setting
losing argument ... as if assignment within condition has been a real
problem except for JSLint ... uhm, I don't think so but I am off this
conversation. Already said my point, feel free to (as usual) disagree ^_^
On Tue, Aug 27, 2013 at 9:48 AM, Brendan Eich wrote:
> On Aug 27, 2013, at 9:42 A
On Aug 27, 2013, at 9:42 AM, Andrea Giammarchi
wrote:
> sure you know everything as soon as you read `of` ... right ?
Wrong. The nested assignment is idiomatic in C but not good for everyone (see
gcc's warning when not parenthesized in such contexts) due to == and = being so
close as to make
> Integer numeric expandos on TypedArrays (eg, outside the range 0..length-1)
> are disallowed by the ES6 spec. in a manner that is independent of
> the[[Extensible]] internal property. The discussion at the meeting was about
> non-numeric expandos such as 'foo'.
Oh. That's just weird O_o.
_
let me rephrase ... I've no idea what this code does if not a syntax error
(and for different reasons)
`for (let m of re.execAll(str) {`
what is `of` ... will `let` mark that variable as local ? what is returned
and what will be `m` ?
I need to know these things ... this has nothing to do with "
> On Aug 27, 2013, at 9:39 AM, Brendan Eich wrote:
>
>> On Aug 27, 2013, at 9:35 AM, Oliver Hunt wrote:
>>
>> Existing types with magic index properties (other than Array) just drop
>> numeric expandos on the floor so it's logically a no-op. Unless there was a
>> numeric accessor on the pr
On Aug 27, 2013, at 9:26 AM, Domenic Denicola wrote:
> I am not aware of all the nuances of the discussion, but as a developer I
> would find the behavior for numeric expandos confusing. For a typed array of
> length 1024, setting `ta[1023]` would do something completely different from
> setti
sure you know everything as soon as you read `of` ... right ? How
objectives are your points ? If you know JS that while looks very simple,
IMO
On Tue, Aug 27, 2013 at 5:24 AM, Claude Pache wrote:
>
> Le 27 août 2013 à 01:23, Brendan Eich a écrit :
>
> > Andrea Giammarchi wrote:
> >> Is it very
On Aug 27, 2013, at 9:35 AM, Oliver Hunt wrote:
> Existing types with magic index properties (other than Array) just drop
> numeric expandos on the floor so it's logically a no-op. Unless there was a
> numeric accessor on the prototype (which non-extensibility does not save you
> from).
Thos
Existing types with magic index properties (other than Array) just drop numeric
expandos on the floor so it's logically a no-op. Unless there was a numeric
accessor on the prototype (which non-extensibility does not save you from).
My complaint is that this appears to be removing functionality
I am not aware of all the nuances of the discussion, but as a developer I would
find the behavior for numeric expandos confusing. For a typed array of length
1024, setting `ta[1023]` would do something completely different from setting
`ta[1024]`. Unlike normal arrays, setting `ta[1024]` would n
The curent argument for non-extensibility seems to be mozilla doesn't support
them. It sounds like all other engines do.
There are plenty of reasons developers may want expandos - they're generally
useful for holding different kinds of metadata. By requiring a separate object
to hold that inf
see meeting notes
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-24.md#54-are-typedarray-insances-born-non-extensible
On Aug 26, 2013, at 5:34 PM, Oliver Hunt wrote:
> So I noticed in the last revision to the TA spec that a decision was made to
> prevent extensibility of
Le 27 août 2013 à 01:23, Brendan Eich a écrit :
> Andrea Giammarchi wrote:
>> Is it very useful because you wrote for instead of while ?
>>
>> ```javascript
>> while (m = re.exec(str))
>> console.log(m[0])
>> ;
>> ```
>
> It is, for two reasons:
>
> 1. in JS only for can have a let or var bi
(Pardon the late reply. Catching up.)
I'd also go with option 1 (accept that [[Invoke]] changes visible order of
side-effects).
Option 2 pollutes the simple interface of [[Invoke]] for compatibility with
edge-cases, which, as MarkM points out, are not fully web-compatible anyway.
The symmetric op
On 26 August 2013 23:18, Allen Wirfs-Brock wrote:
>
> On Aug 26, 2013, at 1:38 PM, Erik Arvidsson wrote:
>
>> On Mon, Aug 26, 2013 at 3:02 PM, Allen Wirfs-Brock
>> wrote:
>>>
>>> On Aug 26, 2013, at 11:37 AM, Erik Arvidsson wrote:
>>>
I agree that this is crucial. I think that tips the balan
23 matches
Mail list logo
