Overall I agree: handling complex data structures and algorithms is difficult within the current event system, and the spirit of this suggestion is to resolve that. I'm not sure I agree with the specifics, but I agree that there is a weakness and that something along the lines of what is suggested would help. However such changes are deep and far-reaching and would require quite some rearchitecting. I don't think we could start addressing this within a C2 time-frame (more like C3, whenever that may be).
I do however have some random points to add to what you've said which might help you realise the situation as it is right now is perhaps not quite so bad as you think:
And I'm fairly certain that the process of creating a sprite, albeit offscreen, is far more resource intensive than manipulating much simpler data.
Not really - sprites are actually very well optimised. If it has no animations, it sits on an invisible layer, and you don't make any collision checks, then IIRC it has no performance overhead from simply existing. This means it's actually a pretty reasonable idea to have some global sprites as a sort of namespaced global variable solution. So you can for example have some variables with names like "Stats.Accuracy", "Inventory.ItemCount", etc.
[quote:1prxrse4]Sprites cannot have arrays, dictionaries, or other Sprites (or even anything remotely object related) as an Instance Variable.
No, but an interesting feature of containers is that you can put an array or dictionary in a container with a sprite, and each instance of a sprite gets its own array/dictionary instance. The way picking works with containers also means once you pick one of those sprites with events, all actions/expressions to do with its contained arrays/dictionaries refer to its own objects only. You can add several arrays or dictionaries to a sprite in its container and have all sorts of per-instance advanced data structures for different purposes. While that's not using instance variables, it achieves the same end, and hopefully is a good workaround.
[quote:1prxrse4]Customer.getInstance("customer1").getValue("Name")
One of my concerns with expressions like this is performance. If "Customer.getInstance" returns an entire customer record with *all* their data, and then you discard it all and retrieve only the name, and then you do that a lot, then there's a lot of wasted effort going on. It's solvable with by-reference passing and so on, but it gets complicated if you want to start adding expressions that modify the result, such as slicing arrays and such.
Other options could include:
- involve this in a new modularity system somehow
- better ways to integrate JS code (which is quite an extreme way to solve the problem I guess)