concord-consortium/lab — pull request #16 by pjanik (2012-10-16 13:00:40+00:00)
Title: Refactor properties and indices of obstacle, add set/getProp methods

@stepheneb, @rklancer
I've wanted to add scripting API for obstacles (set/getObstacleProperties, using new approach). During that work, I've tried to implement my idea from this post:
https://groups.google.com/forum/?fromgroups=#!topic/lab-models/pC1WC0rV1gs

I completely removed INDICES arrays for obstacles. Everything works (except one interactive, where the obstacle is pink instead of yellow, but it should be easy to trace and fix). So, it's a real life example of the idea.

Personally, I can't see any important advantages of INDICES arrays - it's yet another structure, another place to add some strings, longer access for properties while typing etc. Developer has to know the property name in both cases, the only difference is that now he has to access obstacles object (e.g. obstacles.x), instead of indices object (e.g. obstacles[model.OBSTACLE_INDICES.X]). But the first option seems to be compact and straightforward.

Moreover, I would like to:
1. Remove or make use of PROPERTIES_LIST objects.
Now, they are also redundant. The only advantages I can see is that developer has an obvious place to check available properties. Another idea is to copy only subset of these properties in modeler to restrict access to them (so, e.g. "xPrev" and "yPrev" properties of obstacle wouldn't be available in scripting API).
2. Change serialization of colors of obstacle to three separate arrays.
Why? There would be 1:1 matching between serialized properties and properties in "obstacles" object.

Now, 1. and 2. ideas aren't implemented. However, opinions are welcome. ;)

I created this pull request to ask you about options, as I'm not 100% sure if it works for other structures (like atoms, elements, radial bonds etc.) and if you like it. If so and can't see any obvious problems, I can refactor other structures too.