Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

data types: arrays or objects #2

Open
mattdesl opened this issue May 21, 2015 · 6 comments
Open

data types: arrays or objects #2

mattdesl opened this issue May 21, 2015 · 6 comments

Comments

@mattdesl
Copy link
Owner

Things like Vector, Color, Matrix4, etc.

It can be super frustrating dealing with code that looks like this:

tmp[0] = 5
tmp[1] = 0
tmp[2] = 0
obj.translate(tmp)

//or
vec3.add(obj.position, obj.position, somethingElse)

Instead of:

tmp.set(x, y, z)
obj.translate(tmp)

//or
obj.translate(somethingElse)

However.. array types have a lot of benefits including:

  • code re-use; the end goal here is not to create yet another ThreeJS monolith and I don't want to support/maintain custom data types for matrices, quaternions, etc
  • scope creep; there is no fear of scope creep since new features can be built independently of the framework and its data types (like mat4-interpolate)
  • more functional, allows stuff like filter / slice / map
  • n-dimensional algorithms using for loops (e.g. lerp-array)
  • the dimensionality is intrinsic -- vec[0] is accessing the 0th component. this is quite elegant mathematically
  • better composition with other modules; most npm modules use arrays for the above reasons

So I think array types for all these structures is still the best way to go.

But maybe since this is a fairly opinionated "frameworky" tool, there can be some middle ground that has a nicer UX.

@chrisdickinson
Copy link

Posted this on Twitter, but on second thought it'd be good to record here: I think the array format is probably the "right way" to write vectors for minimal {un,}marshalling at module boundaries, though it's somewhat uncomfortable. Given the success JSX has seen wrapping a rather unpalatable base-type in syntactic sugar, it might be good to see about writing a JS transform that makes matrix operations on arrays more natural. As a bonus, as things like SIMD land, it could automatically transpile code to use those optimizations.

@mattdesl
Copy link
Owner Author

Cool idea, especially SIMD. It would be attractive as a Babel plugin even outside of this framework.

@xeolabs
Copy link

xeolabs commented May 21, 2015

I'm totally regretting using objects instead of arrays within SceneJS, since I always need to convert back and forth in order to use standard math functions (eg. glMatrix), which in many cases also incurs garbage collection overhead.

In my next engine I'm using arrays for everything and it's just so much cleaner!

@gregtatum
Copy link

The transform idea sounds intriguing. I think it would need enough pay off to justify that overhead though. I'd love to see some use-cases written out. I'm still torn between objects vs. arrays myself. It's so much easier to write and read object syntax, but when I'm thinking in terms of data structures and array buffers I think in terms of arrays. When I'm moving a box around a scene I think in terms of object syntax.

@reminyborg
Copy link

+1 for arrays. I remember toji's glmatrix used arrays for speed.

@coderitual
Copy link

Don't even think about not using arrays :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants