You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently I have to manage the reference to GL context in every namespace that uses thi.ng.geom.webgl. It would clean the user code a lot if we could remove all the occurrences of gl symbol that are not context creation. Having written a small WebGL library in CLJS myself, I used a dynamic var in the core module, to allow users bind it to their WebGL context somewhere in the app initialization. Then all other namespaces that need GL context, can simply use the symbol required. Eg.
Thanks, @skrat - I will have to think about this a bit more how this might impact scenarios using multiple GL contexts (apart from having to wrap all calls in binding forms). Generally I'm with others who argue to stay away from dynamic vars and I personally quite like the explicit nature of knowing what goes into which fn call. Also, adopting a central state pattern as proposed by re-frame makes these things trivial and more flexible...
Multiple contexts is a no-brainer, even though in most cases you deal with just one, you can nest binding forms and it will always do the right, intuitive thing. It also plays nice with core.async processes. The idea is not to wrap every form in binding, but do it once at the top level. It's the same concept that many clojure.core functions use, eg. the printer. Thank you for accidentally introducing me to re-frame, I'm using reagent, but I somehow missed this, definitely looks interesting. Although I'm not sure how this issue is related to it. Could you elaborate a bit?
Currently I have to manage the reference to GL context in every namespace that uses
thi.ng.geom.webgl
. It would clean the user code a lot if we could remove all the occurrences ofgl
symbol that are not context creation. Having written a small WebGL library in CLJS myself, I used a dynamic var in the core module, to allow users bind it to their WebGL context somewhere in the app initialization. Then all other namespaces that need GL context, can simply use the symbol required. Eg.The text was updated successfully, but these errors were encountered: