Given our increased use of web workers, there’s been more talk about replacing our Enumeration (for example as used in PrimitiveType) with explicit constants. This will avoid losing the prototype across workers and not needing to know when to use “.value.” The downside is we will not see enumeration names in the debugger.
If we’re OK with this - or have better ideas - I’ll put in an issue for some future point in time.
Patrick
I definitely agree that we need to change them. When you say constants, do you mean strings/integers or can we use static objects? Scott would know better, but couldn’t we fix this by having static. non-prototype objects that conform to the same interface? Using closures, we could just have a makeEnumeraiton function that works similarly to the class we have now.
I don’t completely follow the approach you’re describing, but using objects for enum values won’t work for similar reasons to the current problem: the instances posted to web workers won’t match any of the enum values via reference equality.
I forgot about the reference equality issue and was just thinking about the inability to transfer prototype information. Sounds like integer constants are the way to go.
I don’t see how integer constants are better than the current approach. Sure, enums don’t work when passed to workers, but nothing else does, either. It’s easy to solve by cloning on the receiving end. For example, the heightmap tessellator receives an ellipsoid, and is able to use it as one just by doing this first:
var ellipsoid = Ellipsoid.clone(ellipsoidThatCameFromMessageToWorker);
We could add a similar capability for enumerations. You have to know to do this, but you’re not going to get far with Web Workers if you don’t know to do this.
Kevin
Kevin,
Web workers aren’t the only problem. To use enums correctly, we pretty much always have to use the .value for comparison and passing it to some WebGL functions. At one point, Scott and I put a “+” in front of an enum to pass it to an overloaded WebGL function, but I don’t recall the details. In addition, the current enums need to be explicitly constructed if they are read from JSON like CZML or glTF.
This is a trade-off: the current enums are more debugger-friendly, while the proposed enums are easier to code and less error prone.
Patrick
What is the plan here? Have we reached a consensus?
Patrick
I’m fine with Scott’s plan (int values for the enums and helper functions to retrieve data associated with them).