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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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, [email protected] 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 [email protected].
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 [email protected].
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 [email protected].
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 [email protected].
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
