Suggestion: Deliberately mark Singletons

(Cem Karan) #1

I’m following @khionu’s suggestion from this GitHub issue to discuss my thoughts here.

I’m creating a simulator for my PhD research. It would extremely useful to be able to open up multiple windows at once, but have them all tied to the same ECS (see this issue for more details). What I noticed is that I wasn’t really able to do that, but it appeared that this was an accident, not a deliberate design choice to make it a singleton.

My proposal is that Amethyst should assume by default that all objects may have multiple instances created, and to mark any special objects with a special-purpose Singleton marker trait. A process can be put in place to determine if an object should be allowed to be marked as a Singleton, with all appropriate discussion and decisions documented. We can also audit the code for anything marked as a Singleton to decide if that should be changed in the future.

Thoughts?

(Khionu Sybiern) #2

Singletons are only present as Resources. Resources are intended to be globally available singletons.

As I noted on GitHub, we can review case by case where we can move things from being Resources to Components, but a general “default to Components over Resources” rule doesn’t have a lot of value. In a game or game engine, there are plenty of things that are intentionally, sometimes necessarily, singular/global values. This is why we have Resources.

The suggestion, as is, I am against. Whether something is better as a Resource or Component is entirely situational.

(Cem Karan) #3

I’m comfortable with this.

I’m not really comfortable with this. I agree that each case will need to be decided individually, but in my personal opinion, the assumption should be that the ‘thing’ will be a component, unless there is a good reason to make it a resource.

That said, I absolutely agree with you that there are things that should be resources. I absolutely cannot see how an Application could be a component; it just doesn’t make any sense. But this fits into what you were saying earlier about taking things case by case, and is something that could easily be documented as to why it is a resource and not a component. All I’m saying is that if we can’t find a good reason why something must or even should be a resource, then make it a component instead.