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

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

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

Show key headers only | View raw

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.

Back to comp.lang.java.programmer | Previous | Next — Previous 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