hxmath
hxmath copied to clipboard
tbrosman
Clearly mark (possibly through metas) which functions allocate new objects and which do not
Metadata doesn't show up in tooltips. I'd put it in the comments instead.
I see that hxmath has the convention that "apply" functions modify the object in-place, but that isn't applied consistently. And adding "apply" to every in-place function would make hxmath way more verbose, so I don't recommend it.
My preferred approach is to use tense. Present tense verbs (e.g., normalize()) indicate that the function modifies the object in-place. Past tense verbs (e.g., normalized()) indicate that the function makes a new object. (I know you've got a property named normal, and the property part is fine, but the name makes it sound like it's normal to this, not this normalized.)
Another thing I do is return Void when modifying an object in-place. Then if you type var y = x.normalize(), the compiler will alert you. Downside is that you lose the ability to chain function calls, so I get it if you don't like the idea.
The real question is, is the API fixed at this point, or are breaking changes worth considering?
For context: I have about half of a geometry library already written. I was planning to release it, but then realized that I really ought to join forces with something that already exists, rather than competing. hxmath struck me as quite good, and almost covered my use cases, so I settled on that.
My plan is to give hxmath a polish, merge in my new classes, and then use it in my game engine. If you'll accept the changes, perfect, if not, I'll rename my fork and proceed as a separate project. Obviously you don't have to decide yet, but pull requests will be coming.
The real question is, is the API fixed at this point, or are breaking changes worth considering?
Are you still thinking about this?