The lessons learned from exploring this concept have been applied to the standard library’s List class, mostly ignoring the semantic implications of it. I’ll leave this page up in case we ever need to revisit it
This segues into my current collections brainstorming, and Linking! . That page refers to single items as well as collections, but the same issue is at play here.
| Actions \ Structure | Owned 🌽 | Referenced 👉🏽 |
|---|---|---|
| Read only | list<T> |
list<ref<T>> |
| Link only | ❌ | list<ref<T>>(+link) |
| Create only | list<T>(+create) |
list<ref<T>>(+create) |
| Both | ❌ | list<ref<T>(+unlink)>(+create,+link) |
| Actions \ Structure | Owned 🌽 | Referenced 👉🏽 |
|---|---|---|
| Read only | list<T> |
list<ref<T>> |
| Link | ❌ | list<ref<T>>(+) |
| Link & Unlink | ❌ | list<ref<T>(-)>(+) |
| Create only | list<T>(+create) |
list<ref<T>>(+create) |
| Everything | ❌ | list< ref<T>(+-) >(+create,+link) |
| Actions \ Structure | Owned 🌽 | Referenced 👉🏽 |
|---|---|---|
| Read only | list<T> |
list<ref<T>> |
| Link | ❌ | list<ref<T>>(+) |
| Link & Unlink | ❌ | list<ref<T>(-)>(+) |
| Create only | list<T>(+create) |
list<ref<T>>(+create) |
| Everything | ❌ | list< ref<T>(+-) >(+create,+link) |
Yeah this one is ridiculous lol
It’s all pretty verbose
The big question this raises is whether or not it’s useful to introduce an entire new param syntax for this. + and - might be good enough as the only time this should be used is to make easy modifications to the standard library like this. I do like having them available as operators on data types, and this might be too confusing, but at least parentheses can disambiguate this
Also, how do we dynamically indicate these options to the client?
So maybe there should be a distinction between a List and a Collection. Maybe some other alternatives exist. I’m looking for a word that means “all instances of this type” for the “owned” version. Domain is too confusing.
What are the benefits of even having this?