Oliver Hunt oliver at
Wed Jun 2 16:43:12 PDT 2010

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:
const TA =
                       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])
        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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list