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

Groups > comp.lang.java.programmer > #26383

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

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web