Re: [go-nuts] Expected ambigiuous reference error, got a value instead

[Jan Mercl]

I consider foo.bar and f.b to be of the same length, as in length of a
list, 2 in this case, not length of a string. But I failed to be clear
about it.

On Sun, Nov 5, 2017, 17:38 Daniel Skinner  wrote:

> > I don't know when the shallowest depth can occur while not being on
> shortest path
>
> I know the feeling if we're generally talking about data structures and
> algorithms, but with regards to language spec, the only mental reference I
> have for "path" is for "import paths" of which the actual name is
> important. Searching the spec for "path" in fact only turns up references
> to import path.
>
> So on sight, I assumed "shortest path" meant changing `Texture` to `Tex`
> would affect resolution, which I also knew to be incorrect. It's my own
> failing but thanks for pointing me in the right direction as I was at a
> loss for where to even start as the visual cue of `type  A B` vs `type A
> struct {B}` didn't register wrt the desired error for me.
>
> On Sun, Nov 5, 2017 at 10:09 AM Jan Mercl <0xj...@gmail.com> wrote:
>
>> I don't know when the shallowest depth can occur while not being on
>> shortest path.  Note that path was used in this discussion as meaning full,
>> unpromoted path, ie. like if every embedded field of type T was declared T
>> T instead. The actual selector expression is a prefix of this full path.
>>
>> On Sun, Nov 5, 2017, 16:59 Daniel Skinner  wrote:
>>
>>> The spec uses "shallowest depth", not "shortest path", as I assume
>>> saying "path" would imply the given names in a selector expression
>>> determine ambiguity when they do not.
>>>
>>> "shallowest depth" makes the error more clear in my sample where if this:
>>>
>>> type Uniform GLUniform
>>>
>>> is changed to this:
>>>
>>> type Uniform struct {
>>> GLUniform
>>> }
>>>
>>> access to the Value fields would now exist at the same depth and produce
>>> the error I was expecting to see.
>>>
>>> https://golang.org/ref/spec#Selectors
>>>
>>> On Fri, Nov 3, 2017 at 5:38 PM Daniel Skinner  wrote:
>>>
 Right, I've misunderstood why this error is thrown, as in what defines
 ambiguity. Text search of spec for "ambig" only yields results for
 composite literals and avoiding ambiguity in conversions while "shortest"
 yields no results and the only recollection of "shortest path wins" phrase
 I have is back when vendor directory was introduced.

 On Fri, Nov 3, 2017 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:

>
> On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:
>
> > https://play.golang.org/p/Y1UxMgNhWx
> >
> > I ran into this today but don't understand why the compiler isn't
> throwing an ambiguous reference error. Maybe I've misunderstood why this
> error is thrown the few times I've seen it.
>
> No ambiguity here. One of the Value(s) is
> sample.Texture.GLTexture.Value and the other one is sample.Uniform.Value
> and the specs say the shortest path wins.
>
> --
>
> -j
>
 --
>>
>> -j
>>
> --

-j

-- 
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] Expected ambigiuous reference error, got a value instead

[Daniel Skinner]

> I don't know when the shallowest depth can occur while not being on
shortest path

I know the feeling if we're generally talking about data structures and
algorithms, but with regards to language spec, the only mental reference I
have for "path" is for "import paths" of which the actual name is
important. Searching the spec for "path" in fact only turns up references
to import path.

So on sight, I assumed "shortest path" meant changing `Texture` to `Tex`
would affect resolution, which I also knew to be incorrect. It's my own
failing but thanks for pointing me in the right direction as I was at a
loss for where to even start as the visual cue of `type  A B` vs `type A
struct {B}` didn't register wrt the desired error for me.

On Sun, Nov 5, 2017 at 10:09 AM Jan Mercl <0xj...@gmail.com> wrote:

> I don't know when the shallowest depth can occur while not being on
> shortest path.  Note that path was used in this discussion as meaning full,
> unpromoted path, ie. like if every embedded field of type T was declared T
> T instead. The actual selector expression is a prefix of this full path.
>
> On Sun, Nov 5, 2017, 16:59 Daniel Skinner  wrote:
>
>> The spec uses "shallowest depth", not "shortest path", as I assume saying
>> "path" would imply the given names in a selector expression determine
>> ambiguity when they do not.
>>
>> "shallowest depth" makes the error more clear in my sample where if this:
>>
>> type Uniform GLUniform
>>
>> is changed to this:
>>
>> type Uniform struct {
>> GLUniform
>> }
>>
>> access to the Value fields would now exist at the same depth and produce
>> the error I was expecting to see.
>>
>> https://golang.org/ref/spec#Selectors
>>
>> On Fri, Nov 3, 2017 at 5:38 PM Daniel Skinner  wrote:
>>
>>> Right, I've misunderstood why this error is thrown, as in what defines
>>> ambiguity. Text search of spec for "ambig" only yields results for
>>> composite literals and avoiding ambiguity in conversions while "shortest"
>>> yields no results and the only recollection of "shortest path wins" phrase
>>> I have is back when vendor directory was introduced.
>>>
>>> On Fri, Nov 3, 2017 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:
>>>

 On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:

 > https://play.golang.org/p/Y1UxMgNhWx
 >
 > I ran into this today but don't understand why the compiler isn't
 throwing an ambiguous reference error. Maybe I've misunderstood why this
 error is thrown the few times I've seen it.

 No ambiguity here. One of the Value(s) is
 sample.Texture.GLTexture.Value and the other one is sample.Uniform.Value
 and the specs say the shortest path wins.

 --

 -j

>>> --
>
> -j
>

-- 
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] Expected ambigiuous reference error, got a value instead

[Jan Mercl]

I don't know when the shallowest depth can occur while not being on
shortest path.  Note that path was used in this discussion as meaning full,
unpromoted path, ie. like if every embedded field of type T was declared T
T instead. The actual selector expression is a prefix of this full path.

On Sun, Nov 5, 2017, 16:59 Daniel Skinner  wrote:

> The spec uses "shallowest depth", not "shortest path", as I assume saying
> "path" would imply the given names in a selector expression determine
> ambiguity when they do not.
>
> "shallowest depth" makes the error more clear in my sample where if this:
>
> type Uniform GLUniform
>
> is changed to this:
>
> type Uniform struct {
> GLUniform
> }
>
> access to the Value fields would now exist at the same depth and produce
> the error I was expecting to see.
>
> https://golang.org/ref/spec#Selectors
>
> On Fri, Nov 3, 2017 at 5:38 PM Daniel Skinner  wrote:
>
>> Right, I've misunderstood why this error is thrown, as in what defines
>> ambiguity. Text search of spec for "ambig" only yields results for
>> composite literals and avoiding ambiguity in conversions while "shortest"
>> yields no results and the only recollection of "shortest path wins" phrase
>> I have is back when vendor directory was introduced.
>>
>> On Fri, Nov 3, 2017 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:
>>
>>>
>>> On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:
>>>
>>> > https://play.golang.org/p/Y1UxMgNhWx
>>> >
>>> > I ran into this today but don't understand why the compiler isn't
>>> throwing an ambiguous reference error. Maybe I've misunderstood why this
>>> error is thrown the few times I've seen it.
>>>
>>> No ambiguity here. One of the Value(s) is sample.Texture.GLTexture.Value
>>> and the other one is sample.Uniform.Value and the specs say the shortest
>>> path wins.
>>>
>>> --
>>>
>>> -j
>>>
>> --

-j

-- 
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] Expected ambigiuous reference error, got a value instead

[Daniel Skinner]

The spec uses "shallowest depth", not "shortest path", as I assume saying
"path" would imply the given names in a selector expression determine
ambiguity when they do not.

"shallowest depth" makes the error more clear in my sample where if this:

type Uniform GLUniform

is changed to this:

type Uniform struct {
GLUniform
}

access to the Value fields would now exist at the same depth and produce
the error I was expecting to see.

https://golang.org/ref/spec#Selectors

On Fri, Nov 3, 2017 at 5:38 PM Daniel Skinner  wrote:

> Right, I've misunderstood why this error is thrown, as in what defines
> ambiguity. Text search of spec for "ambig" only yields results for
> composite literals and avoiding ambiguity in conversions while "shortest"
> yields no results and the only recollection of "shortest path wins" phrase
> I have is back when vendor directory was introduced.
>
> On Fri, Nov 3, 2017 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>>
>> On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:
>>
>> > https://play.golang.org/p/Y1UxMgNhWx
>> >
>> > I ran into this today but don't understand why the compiler isn't
>> throwing an ambiguous reference error. Maybe I've misunderstood why this
>> error is thrown the few times I've seen it.
>>
>> No ambiguity here. One of the Value(s) is sample.Texture.GLTexture.Value
>> and the other one is sample.Uniform.Value and the specs say the shortest
>> path wins.
>>
>> --
>>
>> -j
>>
>

-- 
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] Expected ambigiuous reference error, got a value instead

[Jan Mercl]

On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:

> https://play.golang.org/p/Y1UxMgNhWx
>
> I ran into this today but don't understand why the compiler isn't
throwing an ambiguous reference error. Maybe I've misunderstood why this
error is thrown the few times I've seen it.

No ambiguity here. One of the Value(s) is sample.Texture.GLTexture.Value
and the other one is sample.Uniform.Value and the specs say the shortest
path wins.

-- 

-j

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

[go-nuts] Expected ambigiuous reference error, got a value instead

[Daniel Skinner]

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

I ran into this today but don't understand why the compiler isn't throwing
an ambiguous reference error. Maybe I've misunderstood why this error is
thrown the few times I've seen 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.