"TheEndless" wrote:
"EnTerr" wrote:
You mean if i want to "extend" an existing component?! I don't want to do that... why would i?
I'd expect at the very least you'd want to extend a Scene node, but if not, you still need a way to hook into it's context, and there's no way to do that without extending it. Additionally, if you want to take advantage of the multi-threading capabilities of SceneGraph, then you'll have to extend the Task node. It can't be used generically, because the "functionName" has to be the name of a function that is defined inside the Task's context, which again, can only be established by specifying the <script/> that belongs to that Task.
Wait - stop for a moment and think what do you really mean by "extend"? What you describe is just the ability to set functions by name for the node (or brute inject a <script/>) - that exactly what i ask for but that is not what "extend" is - extend is a much broader thing!
I think you are having a cognitive bias, in which doing some SG XML programming for a while, it feels to you subclassing is the only - and natural way to do things. It ain't. Imagine for a moment scenography gives me these:
node.setFunction(name as string, fn as function)
node.getFunction(name as string) as function ' optional
node.getFunctions() ' optional, return AA of all functions assoc with a node
Or wait - it could be
even simpler, if addField()/setField()/getField() work with functions too, which are primitive type in B/S (SG already supports Integer, Float, Double, String, Boolean - why not Function?) - e.g. as simple as
node.addField("myFunc", "function", false)
node.myFunc = function() ...
The function assigned may be either a fn literal (i.e. anonymous) or a global fn - no matter because
functions are thread-safe in B/S, they have no state. This is in stark contrast with most any other programming language where there is lexical scope, closures and such and one cannot "rip" safely a function without dragging some entrails / calls having side (d)effects. Not so in B/S! Moreover function objects are primitive, they do not get garbage collected, so no fear that reference count should be maintained between interp threads. It's about time to rip the benefits of this feature (which in other places has been a handicap)!
Now, if i had this feature (it may already exist for all i know - but if not, it's rather simpler to add) - can you think of a reason i would need to "extend" anything into anything?
