Quick little PR to cleanup and think about ThreeView.new_obj() and making sure it's used consistently throughout the codebase. Consistency becomes all the more important when auto-generating code :P
I think this illuminates one potential cleanup area: views that are constructed immediately vs. after promises are resolved. I think there is an opportunity to augment ThreeView to always treat update as a promise (as opposed to on a case by case basis, e.g. MeshView). I think that it should be ok to still use new_obj even when it's being called in a .then clause.
There are a lot of times where the object is constructed along with some relevant calculations:
1) object is constructed, and then follow-up values are specified on the object
2) calculations are made, then the object is constructed.
Seems to me that these calculations required for construction could also go in new_obj. There is only one exception, where the calculations are dependent on some event, e.g. a mouse event.
@SylvainCorlay
Quick little PR to cleanup and think about
ThreeView.new_obj()
and making sure it's used consistently throughout the codebase. Consistency becomes all the more important when auto-generating code :PI think this illuminates one potential cleanup area: views that are constructed immediately vs. after promises are resolved. I think there is an opportunity to augment ThreeView to always treat update as a promise (as opposed to on a case by case basis, e.g. MeshView). I think that it should be ok to still use
new_obj
even when it's being called in a.then
clause.There are a lot of times where the object is constructed along with some relevant calculations: 1) object is constructed, and then follow-up values are specified on the object 2) calculations are made, then the object is constructed.
Seems to me that these calculations required for construction could also go in new_obj. There is only one exception, where the calculations are dependent on some event, e.g. a mouse event.