Community
Participate
Working Groups
I am trying to implement a generic self-type pattern for a family of nested classes. It appears as though certain methods cannot be overridden because the compiler thinks they are not present in a type (compiler error), yet the Eclipse hierarchy view shows the method to be present in that type. The specific circumstance is in trying to create a "wrapper" class, Family.Unmod, for the type Family, with all of the type methods being forwarded to the wrapper "target" object, of type Family. In the attached sample code the compiler errors appear in the Family.Unmod.setFamily() and Family.Unmod.doFamily() methods. Perhaps I am overlooking something obvious, but I've tried coming at this from several different directions and it just seems that either the compiler is broken (methid should be accessible for use) or Eclipse is broken (method should not appear in hierarchy view as accessible for use). Also, it seems odd that the problem only occurs for methods that take a self-type argument, not for the method with no argument.
Created attachment 42439 [details] Base family class This is the base class for a family of related types used for generic self-type extension and concrete type implementation.
Created attachment 42443 [details] Concrete family class This is the concrete class for a family of related types used for concrete type implementation. Note that this is the file that contains the apparent compiler errors, in Family.Unmod.setFamily() and Family.Unmod.doFamily().
A minor correction to my original description. I said "overridden", but it should read...... It appears as though certain methods cannot be *accessed* because...
Created attachment 42458 [details] Concrete family class (take 2) In this version the Family.Unmod simply extends FamilyBase.Unmod from the base family class. Unfortunately, there is a compiler error when trying to use super(), even when Eclipse generates the constructor. I tried casting the target object to various other types just to see if super() could be satisfied, but I couldn't satisfy it. Is this a bug (compiler, or Eclipse constrictor generator)? Perhaps this is related to the other problems (can't access certain methods) when trying to implement the generic self-type pattern.
Could you please provide a complete test case? Your test case refers to the package gumbo2.... that is not included. Thanks. Also specify what build you are using.
It is a BIG package. I'll try to simplify the test case and then repost it.
Created attachment 42497 [details] Base and concrete family classes using the generic self-type pattern Complete standalone test case. Family.java includes both flavors of wrappers, UnmodA and UnmodB, that I previously reported as having compile errors. Refer to the notes in the code.
I am using Eclipse Version: 3.2.0 Build id: I20060519-1206 Which I believe is RC4.
Your test case compiles fine with the upcoming RC6 build. I tried it with I20060519-0010 and I had no compile errors. Could you please check your test case with a more recent build? Thanks.
I just did a clean install with RC5, I20060519-1206 (which is the same version I was previously using, and is the latest stable release available on the eclipse website). I am still seeing compile errors. Did you actually open up the Family.java file to see the errors where I noted them in the code comments? I am only seeing the compile errors when I look in the file itself. The error indicator is not propagating to the tab or explorer view (perhaps this in itself is a bug). (In reply to comment #9) > Your test case compiles fine with the upcoming RC6 build. > I tried it with I20060519-0010 and I had no compile errors. > Could you please check your test case with a more recent build? > Thanks. >
Problem still exists in latest. It occurs only in the editor. The compilation itself works fine.
This is certainly not a blocker since it doesn't prevent you from compiling the classes. Setting severity as normal. Jérôme, The problem seems to be related to the usage of '$' sign as a type variable name. If I rename all the '$' into 'T' it seems to work. I'll try to simplify the test case and validate that the problem comes from the usage of the '$' sign.
The problem in reconciling comes from the usage of the $ sign. Here is a small test case: public interface Base<$> { public $ foo($ t); } public class B<$ extends Base<$>> { $ _t; public $ foo($ t) { return _t.foo(t); } } Save them in two different files. Then go to the class B and edit it. foo in _t.foo(t); will be underlined as having an error even if it compiles fine. Having them in the same file doesn't report any error in reconciling. Hope this test case will help to isolate the issue. Renaming all '$' to 'T' fixes it.
I tried the workaround (renaming $) and it works for me. So, there seems to be two bugs: 1) Although unorthodox, $ should be a valid type name in all contexts. 2) It seems that if any error is detected in a file (whether that error is correctly detected or not) it should be propagated to the rest of eclipse (as indicated in tabs and the explorer tree). BTW: I decided to use $ instead something more normal since the whole concept of generic self-type is so bizzare and twisted, and must be handled with kid gloves. I wanted to make sure that it stood out from any "normal" type.
*** This bug has been marked as a duplicate of 91709 ***
