Sounds like it's also more than a map[type]interface{} and more like either map[type][]interface{} or a map[type]map[uuid]interface{}. And that's somewhat naive as well.
I'd probably implement a method to store and fetch each "type" that the ECS could actually care about, which could probably be generated (see `go help generate`). That may be too onerous though depending on *how* the ECS would be used. I don't have much use for systems like that in what I normally work on. The actual storage of the data may also require a more sophisticated setup than a single top level map as well. There is probably a better way to model a system like this in Go, but I don't know what it is. On Mon, Nov 7, 2016 at 8:27 PM Kaylen Wheeler <kfjwhee...@gmail.com> wrote: Keep in mind: at this point, I'm only playing around with a Go implementation. What I'm trying to do is implement an Entity-Component-System. Each entity consists of a collection of components, each of which may have a different type. The first thing I'm trying to implement is an easy way to look up components by their type and assign them to a variable that points to that type. I want to avoid writing something like foo := e.GetComponent(reflect.TypeOf(&Foo{})) That seems unnecessarily verbose. I also want to avoid explicit type-casting for the same reason. On Monday, 7 November 2016 19:52:06 UTC-8, freeformz wrote: Based on that example, I'm even more confused about what you are trying to accomplish. Can we take a step back and forget about the implementation of a solution and describe the problem you are working on? On Mon, Nov 7, 2016 at 19:08 Kaylen Wheeler <kfjwh...@gmail.com> wrote: Here's what I have so far: https://play.golang.org/p/X2z7Yl9UPg I think it works for my purposes. However, I'm confused about one thing: Why does reflect.Value.Set panic when passed a zero-value? On Monday, 7 November 2016 16:56:52 UTC-8, freeformz wrote: Then just use pointers (see lines 45+): https://play.golang.org/p/vl47WDHOdN On Mon, Nov 7, 2016 at 4:50 PM Kaylen Wheeler <kfjwh...@gmail.com> wrote: I want pointers because I want most components to be structs, and I want the ability to modify the fields in those structs. On Monday, 7 November 2016 16:46:17 UTC-8, freeformz wrote: Why do you want to use pointers? On Mon, Nov 7, 2016 at 4:42 PM Kaylen Wheeler <kfjwh...@gmail.com> wrote: Thanks for the "basic pattern" example here. There's one little modification I'm wondering about. Can this line: rv.Elem().Set(m[rv.Type()]) be changed to this? rv.Elem().Set(*&*m[rv.Type()]) If so, how can we check that the input value is a pointer to a pointer. Or alternatively, is it better that the values in m should be pointers? On Monday, 7 November 2016 16:01:53 UTC-8, adon...@google.com wrote: On Monday, 7 November 2016 17:55:57 UTC-5, Kaylen Wheeler wrote: I'm trying to find a typesafe way to access a type-indexed map of components. This map can contain objects of any type, and the keys are reflect.Type. One strategy I thought may work would be to pass a pointer to a pointer as an out-var. Using reflection to determine the pointer's type, it could be populated with a corresponding value. For instance, if we did something like this: c := ComponentCollection{} c.addComponent(123) // Add an int component var p : *int c.getComponent(&p) In this case, p would point to the int component of c. That's wht the 2 levels of indirection are necessary: it's an out-var to a pointer. Does that make sense? Here's the basic pattern: var m = make(map[reflect.Type]reflect.Value) func addComponent(x interface{}) { v := reflect.ValueOf(x) m[v.Type(x)] = v } func getComponent(ptr interface{}) { rv := reflect.ValueOf(ptr) if rv.Kind() != reflect.Pointer { panic("not a pointer") } rv.Elem().Set(m[rv.Type()]) } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.