On Jun 2, 2010, at 11:14 AM, Brendan Eich wrote:
> On Jun 1, 2010, at 6:15 PM, Waldemar Horwat wrote:
>
>> b = a[i];
>> a[i].x += 1;
>>
>> Now b.x also reflects the new value of a[i].x; i.e. b is an alias, not a
>> mutable copy. The same thing would happen if one had mutated b.x.
>>
>> That leads to a couple plausible meanings of b === a[i]:
>>
>> 1. Pointer equality: True if and only if mutating one's contents would
>> mutate the other's.
>
> That is a good point. Since WebGL demands a[i] be stored as packed machine
> types in-line in a vector of such structs, this is really asking whether b
> aliases a[i]. We could make this work.
I cannot think of a case where b should not be an alias to a[i] if b is not an
alias to a[i] then the code
a[i].x += 1;
Could not modify a[i] itself, effectively we've created an immutable type.
Honestly i think the semantics of the current definition are effectively
something along the lines of the following:
/*
Given:
const TA =
Array.newTypedArray(fixed_length,
Object.newStructType({x:"u32", y:"u32", z:"u32",
r:"u8", g:"u8", b:"u8", a:"u8"}));
*/
Array.newTypedArray = function(length, elementGenerator) {
var result = {};
Object.defineProperty(result, "length", {value: length, writable: false,
configurable: false, enumerable: false});
for (var i = 0; i < length; i++) {
result[i] = elementGenerator();
}
return result;
}
Object.newStructType = function(description) {
return function() {
var result = {};
var value = 0;
for (var property in description) {
if (!description.hasOwnProperty(property)) continue;
Object.defineProperty(result, property, {
get:function(){ return value; },
set:function(coercer) { return function(v){ value =
coercer(v); }; }(description[property])
});
}
result.preventExtensions();
return result;
}
}
function coercer(typeDescription) {
switch (typeDescription) {
case "u32": return function (v){ return [[v ToUInt32]]; }
...
}
}
The delayed/lazy reification of the object storage in this case would be an
implementation optimisation, and would therefore not require any additional
changes to semantics of the language.
>> 2. Recursive value equality: True if and only if all of their constituent
>> elements are ===.
>
> This is what Sam suggested, citing ECMA-334.
I dislike this concept -- it feels too much like we're trying to bring in a new
sense of strict equality.
>> I hope that you can't have things like aliases themselves as first-class
>> values inside structs, as that could create cycles (although you could still
>> make === work in that case if you really wanted to).
>
> The only types WebGL wants inside structs are machine scalar types, ints and
> floats of several sizes. But if we take a broader view, we could try to
> define structs that can contain (typed arrays of) (other) structs, so long as
> everything bottomed out in primitive types.
>
> The complexity of object-reference-typed struct members does not seem worth
> it.
I feel this proposal is incredibly complicated for basically the single use
case of WebGL. The majority of use cases for typed arrays are for homogenous
element types, and I believe most of what WebGL wants could be achieved simply
by use of homogeneously typed arrays that were stepped in a way to avoid
aliasing (this would not be complicated from either implementation or
specification PoV). The usability would likely be better than the current
webgl model, it wouldn't require aliasing, and it would require such a
complicated addition to the language.
--Oliver
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
