> But I miss the linear algebra library to go with it.
Can you send references to example libraries for other systems that you would
like to see?
> Especially for the "binary data" approach, as it's removing an order
> that might be implicitly known - sorry, I don't know how to express that
> better, so I'll make an example:
>
> // A point or vector in projective geometry - as usually used for 3D
> // and advanced 2D:
> const Vec3D = new StructType({ x: float32, y: float32, z: float32, w:
> float32 });
I'm not sure if the wiki page mentions this, but objects are ordered in
JavaScript, and the intention of the spec is to exploit this. The data would be
laid out in order, so that for example when copying the data to a WebGL buffer,
you would get them in the order they appear in the type.
> My suggestion is to create a "duality" for access, i.e.:
> v = new Vec3D;
> v.x = 1.0;
> v[0] == v.x; // -> true
This seems like a reasonable convenience, and maybe also a way to enforce the
ordering of struct fields a little more explicitly in the spec.
(As an aside: part of the purpose of the binary data spec was to avoid casting.
By giving programmers a more expressive library of type descriptors, they can
create compound types that express the kinds of data needed for applications
like WebGL. And we'd really rather avoid providing cast operations, since they
expose platform-specific characteristics like endianness, leading to
portability hazards. So for that reason, I'm loath to allow struct types to be
*cast* to array types. But I don't think there's any harm in allowing indexed
access to struct members.)
> => But this would also require that the order of the elements in the
> {...} of the StructType({...}) is 1:1 mapped to the array positions.
As I say, that was already the intention.
> (AFAIK is currently the order of elements in an Object undefined
> although all browsers seem to keep the initialisation order)
This is something we intend to specify explicitly in the next edition of the
spec. See:
http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
> And, to make sure that a highly optimized implementation (SIMD
> instructions...) is possible, the language standard should predefine the
> most common types (i.e. Vec2Dfloat, Vec3Dfloat and Vec4Dfloat) and
> supply a library to handle those (especially the scalar product, matrix
> vector product and the matrix matrix product)
Yeah, a matrix library would be nice to have. OTOH, we tend to avoid putting
too many libraries in the standard, preferring instead to let the community
experiment with libraries. Your point about optimization is good, though: a
matrix library could be highly optimized by the JS engines, more so than many
other kinds of libraries. Still, in the end it comes down to resources: do we
have the time and people to spec the library; do implementors have the
resources to implement the library; or does someone have the resources to write
an open source implementation that could potentially be shared by the many
VM's...
Thanks for your feedback!
Best,
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
