This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: PR java/19870 (Part 2/2): Handle private static methods accessed across nested classes
- From: Ranjit Mathew <rmathew at gmail dot com>
- To: tromey at redhat dot com
- Cc: GCJ Patches <java-patches at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 19 Jun 2005 23:52:28 +0530
- Subject: Re: PR java/19870 (Part 2/2): Handle private static methods accessed across nested classes
- References: <39399b9d050618200363c78dbe@mail.gmail.com> <m3ll57q6q1.fsf@localhost.localdomain>
- Reply-to: Ranjit Mathew <rmathew at gmail dot com>
On 18 Jun 2005 23:02:46 -0600, Tom Tromey <tromey@redhat.com> wrote:
> >>>>> "Ranjit" == Ranjit Mathew <rmathew@gmail.com> writes:
>
> Ranjit> FAIL: 15.12.3-explicit-constructor-9
>
> Ranjit> The latter confuses me (but both Jikes and javac 1.5.0.03
> Ranjit> compile it without errors). I'd be grateful if someone could
> Ranjit> explain exactly why it should *not* be an error.
>
> The test case:
>
> class T15123ec9 {
> private int m() { return 1; }
> T15123ec9(int i) {}
> class Sub extends T15123ec9 {
> Sub() {
> super(m()); // m is not inherited, so it is the enclosing m
> }
> }
> }
Thank you for pasting the testcase. I ought to have done it
myself and I apologise for the oversight.
> If m() were not private, the call would be to Sub.m(), which would be
> invalid because it would be a use of 'this' in a static context.
What static context?
> However, m() is not inherited. So, the call is to
> 'T15123ec9.this.m()', which is valid as it doesn't refer to the object
> being constructed.
Yes, now I see it. I got a bit confused by the fact that
both 'this$0' and 'this' are instances of T15123ec9 (I
thought them to be the *same* instance...).
Thanks for the explanation.
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/