Generic collections support for ProtoFlux

[Frooxius]

Is your feature request related to a problem? Please describe.

Currently ProtoFlux has no ability to natively work with collections and collection datatypes, such as arrays, lists, hashsets, dictionaries and so on.

This includes interacting with data model collections as well and blocks any functionality that requires collection support - working with JSON, iterating over slots, components, performing raycasts whole results are a collection that needs to be iterated over and so on.

Describe the solution you'd like

A set of generic nodes for working with various collection types - whether it's accessing elements, iterating or mutating those collections (adding/removing/modifying elements).

Using generic support, nodes will allow interacting with a wide variety of collection sources and targets, from the data model, to temporary collections.

Once this set of nodes is implemented, this will allow implementing additional nodes that consume or output collections. E.g. RaycastAll node, which performs a raycast and outputs a list of all hits, which the user can then use generic collection nodes to iterate over.

Describe alternatives you've considered

N/A

Additional Context

This is a pre-requisite: #571

[gameboycjp]

Will strings become a type of collection when this is implemented?

[Frooxius]

You'll likely be able to treat strings as read-only collection of chars.

[Phyn]

Since I have a few questions and suggestions, I'll number them.

1. Will collections be fully generic? Being able to nest types is quite useful and often required for some advanced functionality.
2. Will collection sizes have to be preset, or will fully dynamic collection sizes be an option or just standard? Both of these are quite useful in their own right.
3. Will there be multidimensional collections such as arrays?
4. Will there be a generic iterator, e.g. for element in collection do? If so, will there be a way to iterate over multiple collections in parallel?

[JackTheFoxOtter]

Adding to the questions, will it be possible to link / drive fields on the data model from entries in a collection / dictionary directly?

For the Dash Calendar, we heavily utilized dynamic fields to link fields on the UI panels to fields on the slot data structure, to allow reading / writing from multiple places directly to the stored data without having to create manual syncing methods, which could have been error prone. For those use-cases linking fields to dictionary items would be incredibly useful, as you would then be able to have event handling when values change, and also be able to easily change what item a UI panel is linked to by just changing the path.

The goal here would be being able to point multiple things (UIX, ProtoFlux, etc.) to the same collection and have them automatically stay in sync with one another.

[Frooxius]

@Phyn

1. Yes, they'll be generic, as per title and the post
2. They'll be dynamic, but we'll add some mechanisms to provide limits on how much you can allocate total
3. Yes, multidimensional will be supported too, but those are not directly supported in the data model
4. Yes, the goal for this system is to have support be generic, which will include foreach iterator. This does not mean the iteration will be parallel, multi-threading is a big thing on its own

@JackTheFoxOtter I'm not sure I understand the relationship here. Are you trying to drive a list in the data model from a list stored elsewhere? Or are you wanting to drive individual elements from an element of a list? How are you storing the source list in that case?

[JackTheFoxOtter]

I'm talking about driving individual fields on the datamodel from individual items of a collection stored for example in a (dynamic) variable.

Example: I have a dictionary {'fruit1': {'name': 'Banana'}, 'fruit2': {'name': 'Mango'}} stored in a dynamic variable. I'd like to be able to link individual items in that collection up to fields on the datamodel by specifying their path. So I could for example drive the string field of a TextRenderer from the value 'fruit2.name' of the dictionary. Then, I could have a second object which has a TextEditor that's also driven from the same variable and same path, but this time with writeback, or alternatively write into it with a ProtoFlux node. So I could use that to change the value of 'fruit2.name', which would also update the TextRenderer that's driven by it. By changing the path to 'fruit1.name' for both objects, I could re-use the same functionality, but point it at a different item in the dictionary.

I'm thinking about this in the same way you can sync multiple values using dynamic fields currently. That way, complex system could store structured data in a single dictionary, which can be accessed from multiple places without the creator having to worry about writing the code to sync those systems themselves. But I imagine it would have to be designed to support this use-case, as you would need to be able to listen to changes on individual values within a single collection.

[Frooxius]

Ah yeah, that will be no problem. That's sort of implicit - you can drive anything with any value. It doesn't matter how you source it, as long as you can feed it as an input - you can drive something to be that value.

If you have node to get an item from a collection, then you have a way of sourcing that value from that field and you can just plug it to the drive.

You might need to worry about what you do when the collection mutates and such, but that's kinda separate.

[charlie-sans]

hey froox, got a question. is this coming after the settings rewrite or wayyyyyyy later.

[shiftyscales]

The only currently planned work items are the settings rework (#584 / #614), and the new IK system (#612 / #616), @charlie-sans - and even then- as indicated in this issue, #571 is a prerequisite.

[gameboycjp]

Out of curiosity, why is localness tracking a prerequisite?

[gameboycjp]

Will we be able to at least access and modify texture and mesh data generically by treating their data as collections, or will that be completely locked behind DSP functionality?