-
Notifications
You must be signed in to change notification settings - Fork 4
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
How to handle parametric components #10
Comments
Maybe declare that The lookup can't be fast if we've got a |
Yes, you're right. I was wondering if a simple if haskey(dict, ComponentData)
dict[ComponentData]
else
return getindex.((dict,), filter(x->x isa ComponentData, keys(dict)))
end would be a valid naive implementation with some tradeoff for wanting to use this functionality (i.e. you're not specifically asking for the right things). Again, I guess this would mainly happen outside the innermost loops. But that mentality at some point may bite us in the ass anyway. I was thinking that actually it would be quite nice to have something like a |
I'd potentially write that as get(dict, ComponentData) do
for (k,v) in dict # just the first match?
k isa ComponentData && return v
end
error("...")
end I don't think it's great to return either a vector or a single component, depending on multiple vs single matches. It's pretty hard to reliably use an API where the result might-or-might-not be a collection. Here's another perhaps bad idea — how about detecting when a concrete version of a parametric type is added, and stripping it down to its parent parametric type (eg, using this hack). That should let you retain the Dict and do fast lookup (I guess), only with the caveat that the actual concrete |
I've cleaned up the
@component
macro, there was a slight bug.In doing so I also made it so that now Parametric
ComponentData
types are allowed.This brings up the question of how to best handle this, and if it makes sense to begin with.
e.g.
As you can see from this example, there are some things to consider. First of all, I think I'd like to be able to do
m[Spatial]
, although I'm unsure how exactly this can be performant. Maybe only something like an iterator over all components inm
,<: Spatial
would be useful.Basically, do we like the behavior that is present now?
The text was updated successfully, but these errors were encountered: