, or anything like that in the API.
Sounds good!
Arrays inside structs. Are there plans for this? They're not absolutely
necessary, but often quite handy anyway, for example:
StructType({
unique: uint32[4]
})
That's definitely supported.
Woohoo!
Also, what's the plan with Typed Arrays
? Are typeless properties
allowed in the first place (IIRC there was a talk I watched where David
Herman or someone else said that this might be)? Will you be able to
extract structs out of an ArrayBuffer?
What about strings? Looking through the binary data related proposals,
there seems to be no good way
in the first place (IIRC there was a talk I watched
where David Herman or someone else said that this might be)? Will you be
able to extract structs out of an ArrayBuffer?
I hope so ... MyStructArray = new ArrayType(new
StructType({myStruct:fields}), length) so that new MyStructArray([st])[0
about an ArrayType instance? If they do,
how will it react to typeless properties? Are typeless properties allowed in
the first place (IIRC there was a talk I watched where David Herman or
someone else said that this might be)? Will you be able to extract structs
out of an ArrayBuffer?
What
said that this might
be)? Will you be able to extract structs out of an ArrayBuffer?
Same story: if you have the type object or the type any you can't get at
the underlying ArrayBuffer.
What about strings? Looking through the binary data related proposals, there
seems to be no good way
speed, and this need is evident in the semantics of
proposals such as typed arrays.
Ignoring all such optimization guarantees, the shift and OR code is
ugly and verbose. So there's a usability argument to be made for
arrays of structs, if not typed arrays as proposed.
I'm not sure where
On Tue, Jun 1, 2010 at 6:29 PM, Sam Ruby ru...@intertwingly.net wrote:
On 06/01/2010 09:15 PM, Waldemar Horwat wrote:
I assume that the proposal is that:
const TA =
Array.newTypedArray(fixed_length,
Object.newStructType({x:u32, y:u32, z:u32,
r:u8, g:u8, b:u8, a:u8}));
let a = new TA(...);
On 06/02/2010 03:52 AM, Jason Orendorff wrote:
I'll still maintain that the choice that ECMA 334 takes, namely
that the assignment to b in the example above, makes a mutable
copy is a valid choice.
I would expect
a[0].x = 3;
to modify a[0], not a temporary copy of a[0]. How do you propose
On Wed, Jun 2, 2010 at 7:02 AM, Sam Ruby ru...@intertwingly.net wrote:
On 06/02/2010 03:52 AM, Jason Orendorff wrote:
I'll still maintain that the choice that ECMA 334 takes, namely
that the assignment to b in the example above, makes a mutable
copy is a valid choice.
I would expect
for decimal) that value types should be shallowly frozen.
There's no issue if we separate value types from structs-for-WebGL,
but perhaps that is still premature. What I'd like to get back to is
value types are shallowly frozen, though. Otherwise we are
introducing a new optimization *and* user
On Jun 2, 2010, at 7:50 AM, Brendan Eich wrote:
There's no issue if we separate value types from structs-for-WebGL,
but perhaps that is still premature. What I'd like to get back to is
value types are shallowly frozen, though. Otherwise we are
introducing a new optimization *and* user
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.
2. Recursive value
On 06/02/2010 02:03 PM, Brendan Eich wrote:
On Jun 2, 2010, at 7:50 AM, Brendan Eich wrote:
There's no issue if we separate value types from structs-for-WebGL,
but perhaps that is still premature. What I'd like to get back to is
value types are shallowly frozen, though. Otherwise we
proposing, typed-array-of-struct elements behave like value types when
assigned to (lvalues), so this assertion botches .
Structs can't be fully (mutable) value types without breaking one
equivalence. Yet they can't be reference types or we lose the critical
in-line allocation and packing
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
On Jun 2, 2010, at 4:43 PM, Oliver Hunt wrote:
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
Should be:
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:
...
Hooray for
Oliver Hunt wrote:
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.
That does not logically follow. See my previous message for why.
Waldemar
___
es-discuss
holds. But with the sketchy struct
semantics I've been proposing, typed-array-of-struct elements
behave like value types when assigned to (lvalues), so this
assertion botches .
Structs can't be fully (mutable) value types without breaking one
equivalence. Yet they can't be reference types or we
On Jun 2, 2010, at 10:26 PM, Brendan Eich wrote:
For an expression a[i]j.x,
Sorry, obvious typo adding a 'j' there (keyboard malfunction, and hard
to see in the font I'm looking at!). No confusion in the rest:
the ES specs all evaluate a[i], call GetValue on it if a Reference,
then make
Brendan Eich wrote:
There's an issue with float32 -- IIRC it does not project into float64
(AKA double). All the other types (uint32, what I schematically named
u32 above, etc.) do.
What? The set of all float32's is a proper subset of the set of all float64's.
When devising scalar types for
: True if and only if mutating one's contents would mutate
the other's.
2. Recursive value equality: True if and only if all of their constituent
elements are ===. I hope that you can't have things like aliases themselves as
first-class values inside structs, as that could create cycles
On Jun 1, 2010, at 5:48 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
There's an issue with float32 -- IIRC it does not project into
float64 (AKA double). All the other types (uint32, what I
schematically named u32 above, etc.) do.
What? The set of all float32's is a proper subset of
types. And something
like an identity test would seem to be necessary (as a patch to a
mitigate a mistake) if we were to allow === to be overloaded for
mutable structs-as-values.
Problem solved by requiring shallowly frozen value types. Which means
they cannot be the structs we've talked
, in particular whether === is overloadable,
even stipulating immutable value types. And something like an identity test
would seem to be necessary (as a patch to a mitigate a mistake) if we were
to allow === to be overloaded for mutable structs-as-values.
Problem solved by requiring shallowly
, and paid a semantic
complexity price we must avoid. Non-frozen structs should not be value
types. Frozen structs could be value types, or could be wrapped in
value types or something.
Agreed. Sam?
There are so many undefined terms in that paragraph that I don't know
what I would be agreeing
be
transparently passed by copy. C# got this wrong, and paid a semantic
complexity price we must avoid. Non-frozen structs should not be
value
types. Frozen structs could be value types, or could be wrapped in
value types or something.
Agreed. Sam?
There are so many undefined terms
On May 28, 2010, at 3:12 PM, Dan Ingalls wrote:
[+DanHHIngalls]
Help! You caught me walking out the door to Germany. Will try to
answer in a day or two ;-)
Hi Dan, thanks for replying -- be gentle, I probably sounded like some
fresh kid talking nonsense about the greats from before
Jason Orendorff pointed out
https://wiki.mozilla.org/Jsctypes/api#User-defined_types
from the ctypes (libffi) bindings for SpiderMonkey docs. Excerpt
below. Ctypes is overkill (and unsafe to boot!) but the ability to
generate array and struct types is pretty much what I've been sketching.
endianness: Lightweight
structs. Khronos: it's less efficient to index into those. Why?
Arrays of structs are preferable to sets of homogeneous element arrays
due to cache and convenience effects.
Allen: Trade off lots of different views of scalar values vs. a
richer set of SSE-like
On May 27, 2010, at 11:38 AM, Sam Ruby wrote:
Well-supported arrays of structs (as schemas) might be a satisfactory
compromise. Consensus emerging around that solution.
Structs in ECMA-334 are value types, and consist of members that
also are value types. Would structs in future revisions
On 05/27/2010 03:05 PM, Brendan Eich wrote:
On May 27, 2010, at 11:38 AM, Sam Ruby wrote:
Well-supported arrays of structs (as schemas) might be a satisfactory
compromise. Consensus emerging around that solution.
Structs in ECMA-334 are value types, and consist of members that also
are value
On May 27, 2010, at 1:10 PM, Sam Ruby wrote:
On 05/27/2010 03:05 PM, Brendan Eich wrote:
On May 27, 2010, at 11:38 AM, Sam Ruby wrote:
Well-supported arrays of structs (as schemas) might be a
satisfactory
compromise. Consensus emerging around that solution.
Structs in ECMA-334 are value
On May 27, 2010, at 2:18 PM, Jonas Sicking wrote:
On Thu, May 27, 2010 at 12:05 PM, Brendan Eich bren...@mozilla.com
wrote:
If structs are anything like value types, then I am interested in
participating. I'm particularly interested in working through the
details
of how arithmetic
the primitive-typed
fields, not whole structs.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 05/27/2010 05:29 PM, Brendan Eich wrote:
On May 27, 2010, at 2:18 PM, Jonas Sicking wrote:
On Thu, May 27, 2010 at 12:05 PM, Brendan Eich bren...@mozilla.com
wrote:
If structs are anything like value types, then I am interested in
participating. I'm particularly interested in working
in all three cases, then this is a value [type]
in the ECMA 334 sense of the word. If the answer is false in all
three cases, then I assert that many will find that to be
surprising, particularly in the first expression.
Good questions.
You're right that if we have value types then structs
On May 27, 2010, at 3:47 PM, Brendan Eich wrote:
Good questions.
You're right that if we have value types then structs, even if
schematically defined rather than declared, and used only to
optimize primitive-typed field access, are value types.
Argh, I meant could be value types. Because
On Thu, May 27, 2010 at 12:05 PM, Brendan Eich bren...@mozilla.com wrote:
On May 27, 2010, at 11:38 AM, Sam Ruby wrote:
Well-supported arrays of structs (as schemas) might be a satisfactory
compromise. Consensus emerging around that solution.
Structs in ECMA-334 are value types, and consist
types. See
http://wiki.ecmascript.org/doku.php?id=strawman:value_types#hard_cases
search for ===.
And I previously argued that false would be unexpected, that's how I
came to the conclusion that structs in ECMA 262, just like in ECMA 334,
should be value types.
Value types were conceived
] have the same bits, why would a[0] === a[1] ever be
false?
Because mutability means a[0] and a[1] do not have the same identity,
and code that must care about identity (security, hashing, anything)
must be able to tell the difference between the two structs.
If a[0] and a[1] are immutable
and these
schema structs. They are distinct proposals, but you could tie them
together. I think that would be a mistake at this point, especially
since WebGL folks have no need for operators and literals (as far as I
know).
It is not a matter of whether they need === operators to be defined, but
rather
41 matches
Mail list logo
