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

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

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

Show all headers | View raw

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.

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