Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-09 Thread Egon
tl;dr; version don't write generic code -- write concrete code, but do 
automate the boilerplate stuff...

Now depending on the reasons why you want to use ECS there can be several 
solutions:

two easy solutions:

1. https://play.golang.org/p/Vv2yYpMitg
2. https://play.golang.org/p/RCImpkDWT2

*PS: always ask about the actual problem you are solving, then people can 
orient to the situation much faster.*

On Tuesday, 8 November 2016 06:27:08 UTC+2, Kaylen Wheeler 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({}))
>
> 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  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  
 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  
>> 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()
>
>
> 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 

Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-09 Thread Edward Muller
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  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({}))

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  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  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  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()


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 

Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Kaylen Wheeler
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({}))

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  > 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  
>>> 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  
> 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()


 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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread mhhcbon
is this what you are looking for ?

https://play.golang.org/p/_g2AbX0yHV

see also the related so for what I fund interesting
http://stackoverflow.com/questions/40060131/reflect-assign-a-pointer-struct-value

On Tuesday, November 8, 2016 at 4:07:56 AM UTC+1, Kaylen Wheeler 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  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  
 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()
>>>
>>>
>>> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Edward Muller
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  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  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  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()
>
>
> 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+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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Florin Pățan
I think that you want to write generic code in a language that doesn't have 
generics. 
Also, the description of the problem is incorrect. You describe how you want to 
solve the problem, my using pointers or changing the fields of structs, but you 
never describe the actual problem, how did you end up with that as a solution? 
What drove you to it?

-- 
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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Kaylen Wheeler
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  > 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()


 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Edward Muller
Then just use pointers (see lines 45+): https://play.golang.org/p/vl47WDHOdN

On Mon, Nov 7, 2016 at 4:50 PM Kaylen Wheeler  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  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()


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+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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Edward Muller
Why do you want to use pointers?

On Mon, Nov 7, 2016 at 4:42 PM Kaylen Wheeler  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()
>
>
> 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+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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Edward Muller
This was also my swag at an example: https://play.golang.org/p/QG7g9veKEI

PS: it's still not strictly "type safe".

On Mon, Nov 7, 2016 at 4:46 PM Edward Muller  wrote:

> Why do you want to use pointers?
>
> On Mon, Nov 7, 2016 at 4:42 PM Kaylen Wheeler 
> 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()
>
>
> 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+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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Michael Jones
Oh, I did not understand it that way. The clarified point is certainly true. 
Inherently true in the sense of a tautology—“When we use mechanisms that delay 
type testing until runtime then we will not have tested the types before 
runtime.” Q.E.D.

 

From: <golang-nuts@googlegroups.com> on behalf of <paraiso.m...@gmail.com>
Date: Monday, November 7, 2016 at 4:30 PM
To: golang-nuts <golang-nuts@googlegroups.com>
Cc: <edwar...@interlix.com>, <kfjwhee...@gmail.com>
Subject: Re: [go-nuts] Noob question: Pointers to interfaces

 

The point freeformz is making is that you loose compile time type safety. Your 
program can still be made type safe at runtime (i.e. not panic) but it's a cop 
out. Sometimes it is worth it since Go type system is limited in comparison of 
its reflection lib which basically allows anything, sometimes it isn't. 
interface{} means turning Go into a dynamic language.

Le mardi 8 novembre 2016 01:09:10 UTC+1, Michael Jones a écrit :

Not precisely so…Interfaces, and type switches, and related mechanisms are 
safe. Their type indeterminism is protected from the program and their 
concretization is much like Schrodinger’s box…the interface is any type until 
you look at it through a type switch or type dereferencing…then it is a living 
concrete type of an expected type or else, like the cat, your program is dead. 

 

From: <golan...@googlegroups.com> on behalf of Edward Muller 
<edwa...@interlix.com>
Date: Monday, November 7, 2016 at 4:05 PM
To: Kaylen Wheeler <kfjwh...@gmail.com>, golang-nuts <golan...@googlegroups.com>
Subject: Re: [go-nuts] Noob question: Pointers to interfaces

 

FWIW: As soon as interface{} is involved you are no longer "type safe".

 

On Mon, Nov 7, 2016 at 2:56 PM Kaylen Wheeler <kfjwh...@gmail.com> wrote:

So, what I'm trying to accomplish is a little unusual, and may need some 
explanation.

Basically, 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()


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?

--
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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Dan Kortschak
Thank you Michael for that. I have written a small package to help with
this kind of uncertainty :)

https://play.golang.org/p/vSnG-HGdrU

On Mon, 2016-11-07 at 16:08 -0800, Michael Jones wrote:
> Not precisely so…Interfaces, and type switches, and related
> mechanisms are safe. Their type indeterminism is protected from the
> program and their concretization is much like Schrodinger’s box…the
> interface is any type until you look at it through a type switch or
> type dereferencing…then it is a living concrete type of an expected
> type or else, like the cat, your program is dead. 



-- 
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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Michael Jones
Not precisely so…Interfaces, and type switches, and related mechanisms are 
safe. Their type indeterminism is protected from the program and their 
concretization is much like Schrodinger’s box…the interface is any type until 
you look at it through a type switch or type dereferencing…then it is a living 
concrete type of an expected type or else, like the cat, your program is dead. 

 

From: <golang-nuts@googlegroups.com> on behalf of Edward Muller 
<edwar...@interlix.com>
Date: Monday, November 7, 2016 at 4:05 PM
To: Kaylen Wheeler <kfjwhee...@gmail.com>, golang-nuts 
<golang-nuts@googlegroups.com>
Subject: Re: [go-nuts] Noob question: Pointers to interfaces

 

FWIW: As soon as interface{} is involved you are no longer "type safe".

 

On Mon, Nov 7, 2016 at 2:56 PM Kaylen Wheeler <kfjwhee...@gmail.com> wrote:

So, what I'm trying to accomplish is a little unusual, and may need some 
explanation.

Basically, 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()


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?

--
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.


-- 
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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Edward Muller
FWIW: As soon as interface{} is involved you are no longer "type safe".

On Mon, Nov 7, 2016 at 2:56 PM Kaylen Wheeler  wrote:

> So, what I'm trying to accomplish is a little unusual, and may need some
> explanation.
>
> Basically, 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()
>
>
> 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?
>
> --
> 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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread adonovan via golang-nuts
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()
>
>
> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Kaylen Wheeler
So, what I'm trying to accomplish is a little unusual, and may need some 
explanation.

Basically, 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()


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?

-- 
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.


Re: [go-nuts] Noob question: Pointers to interfaces

2016-11-07 Thread Pietro Gagliardi
The same explanation that applies to slices of interfaces 
(https://golang.org/doc/faq#convert_slice_of_interface 
) applies to pointers to 
interfaces. You shouldn't need a pointer to interface anyway; what are you 
trying to do?
> On Nov 7, 2016, at 1:16 AM, Kaylen Wheeler  wrote:
> 
> I'm new to Go, and I'm still trying to figure it out.  I'm trying to write a 
> function that takes a pointer to a pointer of any type.
> 
> I tried writing it like this:
> 
> type MyStruct struct {
>   a int
>b int
> }
> 
> func myFunc(p **interface{}) {
>   fmt.Printf("Here is the type: %T\n", p)
> }
> 
> func main() {
>var m *MyStruct
>  myFunc()
> }
> 
> However, I get the error:
> 
> .\main.go:32: cannot use  (type **MyStruct) as type **interface {} in 
> argument to myFunc
> > Elapsed: 1.001s
> > Result: Error
> 
> Is there any way to do this?
> 
> 
> -- 
> 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.