Change signature of Global constructor

[rossberg]

To form a forward-compatible basis for the JS API type reflection proposal, I'm proposing two minor changes to the signature of the JS-side Global constructor:

1. move the value parameter out of the descriptor (already done),
2. rename the type field to something else, e.g., value or content (similar to the element in table descriptors).

Tothether these make the descriptor into a suitable representation of a Wasm global type, which would be compatible with other occurrences of this type in the proposed reflection API.

(The motivation for renaming the type field is that the whole descriptor represents the "type" of the global, so the field should be given a more specific name.)

[binji]

maybe valueType? Or are we planning on adding non-valuetype globals?

[rossberg]

Hm, seems a bit redundant, as it is part of a type description already. The API doesn't say elementType or parameterTypes either. I'd pick a name that captures what thing the field classifies, not what its own (meta)type is.

[binji]

OK, so by that argument it should be value, since elemtype -> element. But I think value is a confusing name:

let g1 = new WebAssembly.Global({value: 100});  // Error!
let g2 = new WebAssembly.Global({value: 'i32'}, 100);  // OK
g2.value  // => 100
WebAssembly.Global.type(g2).value  // => 'i32'

[lars-t-hansen]

I agree 'value' is confusing. The name should have 'type' in it. 'contentType'? (Personally I think 'type' is unambiguous and that the motivation is on the weak side, but any clear alternative is probably OK.)

[rossberg]

Note that it is part of a type already. With the JS type reflection proposal, type would lead to import.type.type, which is odd. Even import.type.valueType would be an awkward redundancy.

I see the possible confusion with value, so how about content? That is the closest analogue to element or parameters.

[binji]

Trying out content:

let g = new WebAssembly.Global({content: 'i32'}, 123);

g.value  // => 0

WebAssembly.Global.type(g).content  // => 'i32'

let globalType = WebAssembly.Global.type(g);
globalType.content  // => 'i32'

I still think valueType looks the nicest, even if it does have the odd redundancy:

let g = new WebAssembly.Global({valueType: 'i32'}, 123);

g.value  // => 0

WebAssembly.Global.type(g).valueType  // => 'i32'

let globalType = WebAssembly.Global.type(g);
globalType.valueType  // => 'i32'

[lukewagner]

The expression import.type.type does make the redundancy more apparent. I kindof like element because it doesn't have the "is this the value or the value's type?" ambiguity of value and content. Also, once reference-types are fully realized, Globals are basically just cheap, single-element tables.

[binji]

We discussed this in the May 15th CG meeting and decided to use value.

[ericprud]

Does the decision mentioned above close this issue?

[binji]

Yes, closing.