Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Viewing one of two views with Either #219

Open
Anders429 opened this issue Apr 24, 2023 · 1 comment
Open

Viewing one of two views with Either #219

Anders429 opened this issue Apr 24, 2023 · 1 comment
Labels
A - Querying Area: Querying components of entities. C - Enhancement Category: New feature or request. C - Usability Category: How easy it is for users to use the library. P - Low Priority: Not particularly urgent. S - Needs Investigation Status: Further investigation is needed. V - Minor Breaking Change Versioning: Requires a minor bump according to semver.

Comments

@Anders429
Copy link
Owner

Just an idea I had this afternoon:

There may be times where we want to have a view on exactly one of two component types. For example, a system could want entities that contain either component A or component B, but not both, and obtain either a mutable reference to A or an immutable reference to B. We can do this now with a view like Views!(&mut A, &B) combined with a filter to express an XOR (not going to write it out because it will be long), but we still have to match on both views in the iteration, and have a weird case where the views seem like they can both be None or both be Some, but the filter has to expressly forbid it.

To make this easier, I think we should add new view type in Either<&mut A, &B> (or whatever other views we want to put in there). This will, naturally, imply the XOR filter, but will also represent the exclusive disjunction directly in the view. There is no question about whether neither or both components is valid, because those states are no longer valid at all.

As far as claims go, a view of this type will make claims on components viewed in both sides. This can also be used for EntryViews, but I'm not sure what this will mean for internal queries: will they be allowed to query both components A and B together? There may also be some problems with subviews.

For resource views, this doesn't really make much sense, since both resources will always exist if they are contained in the resource component list. Just as entity::Identifier does not view resources, I think it best to not view them with Either (or Option, really, but at least that makes sense in that it has ).

There may be some use in nesting these views. If there are three components that want to be viewed with exclusive disjunction, this could be expressed with a nested Either<&A, Either<&B, &C>>. With a view like this, we still have only one valid state, and the filter should naturally follow.

@Anders429 Anders429 added C - Enhancement Category: New feature or request. S - Needs Investigation Status: Further investigation is needed. P - Low Priority: Not particularly urgent. A - Querying Area: Querying components of entities. V - Minor Breaking Change Versioning: Requires a minor bump according to semver. C - Usability Category: How easy it is for users to use the library. labels Apr 24, 2023
@Anders429
Copy link
Owner Author

For reference, the XOR filter would look like this:

filter::And<filter::Or<filter::Has<A>, filter::Has<B>>, filter::Not<filter::And<filter::Has<A>, filter::Has<B>>>>

This is the equivalent of (has(A) || has(B)) && !(has(A) && has(B)). I'm not sure if there is any value in adding a dedicated filter::Xor type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A - Querying Area: Querying components of entities. C - Enhancement Category: New feature or request. C - Usability Category: How easy it is for users to use the library. P - Low Priority: Not particularly urgent. S - Needs Investigation Status: Further investigation is needed. V - Minor Breaking Change Versioning: Requires a minor bump according to semver.
Projects
None yet
Development

No branches or pull requests

1 participant