Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26376 > unrolled thread

pushing the JLS envelope... (6.4.2. Obscuring)

Back to article view | Back to comp.lang.java.programmer

Contents

  pushing the JLS envelope... (6.4.2. Obscuring) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-18 23:48 +0000
    Re: pushing the JLS envelope... (6.4.2. Obscuring) Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-10-19 02:49 +0200
      Re: pushing the JLS envelope... (6.4.2. Obscuring) Lew <lewbloch@gmail.com> - 2013-10-19 14:41 -0700
      Re: pushing the JLS envelope... (6.4.2. Obscuring) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-20 21:33 +0000
        Re: pushing the JLS envelope... (6.4.2. Obscuring) Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-10-22 12:27 +0200

#26376 — pushing the JLS envelope... (6.4.2. Obscuring)

Ok, I know that this breaks conventions and common sense, but
just for the sake of understanding the JLS...

--- snip  foo/Foo.java ---
package foo;
public class Foo {
   public static String bad_name = "boo!"; // bad name for a field
   public static class  bad_name { // even worse, because lower case
      public static void foo() { }
   }
   static {
      bad_name.foo(); // doesn't work, because field obscures type - Ok.
      foo.Foo.bad_name.foo(); // fqn doesn't work, either, but shouldn't it?
   }
}
--- end snip ---

JLS (6.4.2. Obscuring) has to say about this case:
 - If a field name obscures a type name, then a
    fully qualified name for the type can be used
    unless the type name denotes a local class (§14.3). 
("bad_name" isn't a local class, so the "unless"-part doesn't apply.)

Even if the field was non-static, the compiler still doesn't use
the type but rather complains about unavailability of the field,
even with the fqn.

PS: suggesting "rename the field or (better) the type" as a solution
    is really missing the point of this post.

[toc] | [next] | [standalone]

#26377

On 2013-10-19 01:48, Andreas Leitgeb allegedly wrote:
> Ok, I know that this breaks conventions and common sense, but
> just for the sake of understanding the JLS...
> 
> --- snip  foo/Foo.java ---
> package foo;
> public class Foo {
>    public static String bad_name = "boo!"; // bad name for a field
>    public static class  bad_name { // even worse, because lower case
>       public static void foo() { }
>    }
>    static {
>       bad_name.foo(); // doesn't work, because field obscures type - Ok.
>       foo.Foo.bad_name.foo(); // fqn doesn't work, either, but shouldn't it?
>    }
> }
> --- end snip ---
> 
> JLS (6.4.2. Obscuring) has to say about this case:
>  - If a field name obscures a type name, then a
>     fully qualified name for the type can be used
>     unless the type name denotes a local class (§14.3). 
> ("bad_name" isn't a local class, so the "unless"-part doesn't apply.)
> 
> Even if the field was non-static, the compiler still doesn't use
> the type but rather complains about unavailability of the field,
> even with the fqn.
> 
> PS: suggesting "rename the field or (better) the type" as a solution
>     is really missing the point of this post.
> 

The FQN is ambiguous. According to [6.5.2. Reclassification of
Contextually Ambiguous Names]:
>>>>>>
  If the name to the left of the "." is reclassified as a TypeName, then:

    If the Identifier is the name of a method or field of the type
denoted by TypeName, this AmbiguousName is reclassified as an
ExpressionName.

    *Otherwise*, if the Identifier is the name of a member type of the
type denoted by TypeName, this AmbiguousName is reclassified as a TypeName.
<<<<<<

Ergo, foo.Foo.bad_name refers to foo's the member of type String,
bad_name (great name btw.).



... At least that's how I'd interpret it.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#26383

Daniele Futtorovic wrote:
> Andreas Leitgeb allegedly wrote:
>> Ok, I know that this breaks conventions and common sense, but
>> just for the sake of understanding the JLS...
>> 
>> --- snip  foo/Foo.java ---
>> package foo;
>> public class Foo {
>>    public static String bad_name = "boo!"; // bad name for a field
>>    public static class  bad_name { // even worse, because lower case
>>       public static void foo() { }
>>    }
>>    static {
>>       bad_name.foo(); // doesn't work, because field obscures type - Ok.
>>       foo.Foo.bad_name.foo(); // fqn doesn't work, either, but shouldn't it?
>>    }
>> }
>> --- end snip ---
>> 
>> JLS (6.4.2. Obscuring) has to say about this case:
>>  - If a field name obscures a type name, then a
>>     fully qualified name for the type can be used
>>     unless the type name denotes a local class (§14.3). 
>> ("bad_name" isn't a local class, so the "unless"-part doesn't apply.)
>> 
>> Even if the field was non-static, the compiler still doesn't use
>> the type but rather complains about unavailability of the field,
>> even with the fqn.
>> 
>> PS: suggesting "rename the field or (better) the type" as a solution
>>     is really missing the point of this post.
>> 

Great question.

> The FQN is ambiguous. According to [6.5.2. Reclassification of

Great answer.

> Contextually Ambiguous Names]:
> >>>>>>
>   If the name to the left of the "." is reclassified as a TypeName, then:
> 
>     If the Identifier is the name of a method or field of the type
> denoted by TypeName, this AmbiguousName is reclassified as an
> ExpressionName.
> 
>     *Otherwise*, if the Identifier is the name of a member type of the
> type denoted by TypeName, this AmbiguousName is reclassified as a TypeName.
> <<<<<<
> 
> Ergo, foo.Foo.bad_name refers to foo's the member of type String,
> bad_name (great name btw.).

"bad_name" == great name.

> ... At least that's how I'd interpret it.

Makes sense to me, both question and answer.

I shall rethink it a couple or few more times, but so far you seem to have it aright.
If so, then

foo.Foo.bad_name.foo(); // fqn doesn't work, either, but shouldn't it? 

would fail to compile because 'String' doesn't have a method 'foo()'.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#26395

Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
> On 2013-10-19 01:48, Andreas Leitgeb allegedly wrote:
>> Ok, I know that this breaks conventions and common sense, but
>> just for the sake of understanding the JLS...
>> --- snip  foo/Foo.java ---
>> package foo;
>> public class Foo {
>>    public static String bad_name = "boo!"; // bad name for a field
>>    public static class  bad_name { // even worse, because lower case
>>       public static void foo() { }
>>    }
>>    static {
>>       bad_name.foo(); // doesn't work, because field obscures type - Ok.
>>       foo.Foo.bad_name.foo(); // fqn doesn't work, either, but shouldn't it?
>>    }
>> }
>> --- end snip ---
>> JLS (6.4.2. Obscuring) has to say about this case:
>>  - If a field name obscures a type name, then a
>>     fully qualified name for the type can be used
>>     unless the type name denotes a local class (§14.3). 
>> ("bad_name" isn't a local class, so the "unless"-part doesn't apply.)

My fault for stopping reading at (6.4.2) in the JLS...

It seems that "Obscuring" is really only meant between some 
visible field and some visible type which however stem from
different qualifying paths (or local versus qualifyable).

> The FQN is ambiguous. According to [6.5.2. Reclassification of
> Contextually Ambiguous Names]:

Thanks for pointing that out (although I had to read all the
6.5 and 6.5.1 to make any sense of the quoted part of 6.5.2 :-) !

After having determined "foo.Foo" as a Type and considering
Identifier "bad_name":

>     If the Identifier is the name of a method or field of the type
> denoted by TypeName, this AmbiguousName is reclassified as an
> ExpressionName.
>
>     *Otherwise*, if the Identifier is the name of a member type of the
> type denoted by TypeName, this AmbiguousName is reclassified as a TypeName.

So, this is, where field "bad_name" wins over type "bad_name" and
that is regardless that the next identifier is not a member of that
field's type.

Now, I'm going to be (unsolicitedly) sadistic, maybe causing some cringe...
In my example, if I rewrote the static initializer block as follows:
   static { bad_name bad_name = null; bad_name.foo(); }
then it becomes "correct" w.r.t. the JLS, because the name now first
appears in a context that infers a type name, then as a local variable
that beats the field ;-)

Thanks, Daniele, for pointing out, that "Obscuring" wasn't the case.

[toc] | [prev] | [next] | [standalone]

#26402

On 2013-10-20 23:33, Andreas Leitgeb allegedly wrote:
> Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
>> On 2013-10-19 01:48, Andreas Leitgeb allegedly wrote:
>>> Ok, I know that this breaks conventions and common sense, but
>>> just for the sake of understanding the JLS...
>>> --- snip  foo/Foo.java ---
>>> package foo;
>>> public class Foo {
>>>    public static String bad_name = "boo!"; // bad name for a field
>>>    public static class  bad_name { // even worse, because lower case
>>>       public static void foo() { }
>>>    }
>>>    static {
>>>       bad_name.foo(); // doesn't work, because field obscures type - Ok.
>>>       foo.Foo.bad_name.foo(); // fqn doesn't work, either, but shouldn't it?
>>>    }
>>> }
>>> --- end snip ---
>>> JLS (6.4.2. Obscuring) has to say about this case:
>>>  - If a field name obscures a type name, then a
>>>     fully qualified name for the type can be used
>>>     unless the type name denotes a local class (§14.3). 
>>> ("bad_name" isn't a local class, so the "unless"-part doesn't apply.)
> 
> My fault for stopping reading at (6.4.2) in the JLS...
> 
> It seems that "Obscuring" is really only meant between some 
> visible field and some visible type which however stem from
> different qualifying paths (or local versus qualifyable).
> 
>> The FQN is ambiguous. According to [6.5.2. Reclassification of
>> Contextually Ambiguous Names]:
> 
> Thanks for pointing that out (although I had to read all the
> 6.5 and 6.5.1 to make any sense of the quoted part of 6.5.2 :-) !
> 
> After having determined "foo.Foo" as a Type and considering
> Identifier "bad_name":
> 
>>     If the Identifier is the name of a method or field of the type
>> denoted by TypeName, this AmbiguousName is reclassified as an
>> ExpressionName.
>>
>>     *Otherwise*, if the Identifier is the name of a member type of the
>> type denoted by TypeName, this AmbiguousName is reclassified as a TypeName.
> 
> So, this is, where field "bad_name" wins over type "bad_name" and
> that is regardless that the next identifier is not a member of that
> field's type.
> 
> Now, I'm going to be (unsolicitedly) sadistic, maybe causing some cringe...
> In my example, if I rewrote the static initializer block as follows:
>    static { bad_name bad_name = null; bad_name.foo(); }
> then it becomes "correct" w.r.t. the JLS, because the name now first
> appears in a context that infers a type name, then as a local variable
> that beats the field ;-)

You're such a dirty man, you know that? ;P

> Thanks, Daniele, for pointing out, that "Obscuring" wasn't the case.

Thank you for giving me the opportunity to find out what was happening
there.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web