Are we planning on keeping our own Math object around, or will its functions eventually be broken out into their own file now that we use AMD? I need to add a factorial method and wasn’t sure if I should put it in it’s own file (like every other stand-alone function) or make it part of Math.
My preference would be that everything in math gets broken out into it’s own file, for consistency and then Math get renamed to Constants, once that’s all that’s left in it.
Thoughts?
Matt
I haven’t thought about it recently, but before AMD, I actually did the opposite - I combined Constants, Trig, and Math because I could never remember what was in what. My gut is that all the math functions should be in our Math object just like the JavaScript Math object contains math functions. In fact, I look at ours like the missing JavaScript math functions. If that it not the standard in the brave new world of AMD, then I am all ears. Some functions elsewhere that don’t form a cohesive whole may be stand-alone functions not associated with an object because, conceptually, there is no reasonable object to associate them with.
Just curious - what are you computing factorials for? Interpolation?
Patrick
I'm certainly not against having common items grouped together. I
guess my hang-up was that "Math" is super-generic. I mean we
certainly do a lot of math all over the code. I'm okay with keeping
everything as is until we find a compelling reason to change it.
Yes, interpolation; Hermite uses it. Since there's lots of slow ways
to compute factorial, I figured a common optimized version should
probably be made available.
I think one of the JavaScript books, either JavaScript: The Good Parts or High Performance JavaScript has a really slick way of computing factorials and caching the result, but you probably already found it.
Patrick
I hadn't checked High Performance JS, so I just took a look. The cool
thing about his version is that he wrote a generic function memoizer;
but it's actually slower than a version memoized specifically for
factorial (because we can maintain a contiguously indexed array).
The whole thing is probably moot anyway, since Javascript can only
represent whole numbers up until around 25!, but memoization is cool
nonetheless.
So AMD seems obviously the right choice for defining and loading modules, but what I haven’t found is any consensus on what a module should consist of. In CommonJS a module often seems pretty big, like an entire namespace. My approach when I converted Cesium to modules was to make them pretty small, one “class” per module. Erring on the side of smaller modules is really the only way to let an optimizer make applications small by only including modules that are needed.
Math is one that I couldn’t decide on. Here’s some other possibilities that I didn’t do:
Copy all of the functions from JavaScript Math to our Math, and rename it from CesiumMath to Math everywhere. This could be confusing, but it makes CesiumMath into “Math plus more”.
Make a subfolder called Math, put one function per module in there. require([‘Core/Math/toRadians’]) The problem with this is that functions are often used in groups, e.g. toRadians/toDegrees so the result is even more module IDs in the (already overlong) require lists.
Break them up into smaller pieces that make some kind of organization sense. At the time I didn’t want to tackle that, but maybe that’s the best overall. If we do this, I would suggest not having anything so generically named as “Math” at all.
On the other end of the spectrum is Core/FAR, which I think is egregiously bad, but in the opposite direction. Sorry.
LOL, I hadn't noticed FAR yet. Maybe that should go into Math? I
think I like both your Math folder and Math + more object approaches.
With the folder, we could still just separate out the functions and
keep a Constants object.
This all being said, with our ever growing todo list, this has to be
one of the lower priority things we should be worrying about, so now I
regret opening my mouth 
Agreed. Let’s do nothing now. This needs more discussion and we are all working much more important things.
Patrick