From: Arno P. <ar...@pu...> - 2009-09-09 12:30:27
|
actually, it gets even more complicated, because you can also write super.x. In this case the inheritance hierarchy is searched for the next occurrence of x (and yes, they are distinct members). I think I have an idea on how to solve this. Need to brood about it a little more... Arno Brian Schimmel wrote: > Hi Arno, > you're right, the problem is not specific to internal classes. I was > unsure if in the example you provided those two fields called "x" are > the same ones or different ones which just happen to have the same name. > I extended the test so that it showed me what's the expected behavior on > Java: > > public class Test > { > public static void main(String[] args) { > TestDerived b = new TestDerived(); > b.setXbase(1); > b.setXderived(2); > > System.out.println("b.x (should be 2): " + b.x); > System.out.println("b.getXbase() (should be 1): " + > b.getXbase()); > System.out.println("b.getXderived() (should be 2): " + > b.getXderived()); > System.out.println("((TestBase)b).x (should be 1): " + > ((TestBase)b).x); > System.out.println("((TestDerived)b).x (should be 2): " + > ((TestDerived)b).x); > } > } > > class TestBase { > public int x; > > int getXbase() > { > return x; > } > > void setXbase(int x) > { > this.x = x; > } > } > > class TestDerived extends TestBase > { > public int x; > > int getXderived() > { > return x; > } > > void setXderived(int x) > { > this.x = x; > } > } > > So we should try to find a solution that ensures the same behavior on > Objective C, and the code above might be useful the check it. > > On the other hand, I don't know if anybody would seriously implement > something like that, that is, using two fields with the same name and > rely on then being handled independantly. > > In my case (the multiple inner classes) the both fields called "this$0" > may be independant fields, but they are final and guarenteed to contain > a reference to the same object, so it does not matter to me if XMLVM > somehow confuses the two. > > By the way, I guess the same problem might pop up for other target > platforms too. > > Brian > > > 2009/9/9 Arno Puder <ar...@pu... <mailto:ar...@pu...>> > > > Never mind my last message. I know the source of the problem. Here is an > example that will break XMLVM: > > > class TestBase { > public int x; > } > > > public class TestDerived extends TestBase { > public int x; > } > > In Objective-C you can only have one member of the same name along an > inheritance path. Kind of makes sense when you consider that Objective-C > is a dynamically typed language. > > I'm not sure what is the best way to deal with this. Name mangling comes > to mind (include the class name in the member's name), but perhaps there > is an easier way. > > Arno > > > > Brian Schimmel wrote: > > Hi, > > > > I'm completely new to XMLVM, but due to the external > circumstances, I'm > > forced to do something rather advanced with it, that is, a > > crosscompilation of the Java 6.0 Collections Framework to > Objective C. > > You might argue that it might be better to use native Objective C > > collections and write bridges, but as I need to get the same > behaviour > > as on Java, I thought crosscompiling would be nice. To make things > > easier for XMLVM I already used Retrotranslator to crosscompile > the Java > > 6.0 classes to Java 1.2, and checked their validity on J2ME. As > far as I > > can tell, my Java classes are 1.2 compilant and working, but > > crosscompilation to Objective C has its quirks. > > > > Let me first outline the class layout: > > > > abstract class AbstractList extends AbstractCollection implements > List > > { > > class Itr implements Iterator > > { > > //... > > } > > > > class ListItr extends Itr implements ListIterator > > { > > //... > > } > > > > //.. > > } > > > > AbstractList has two inner classes and one of those inherits from the > > other one. The problem is, that both AbstractList$Itr and > > AbstractList$ListItr have the following synthetic member in their > bytecode: > > > > final synthetic AbstractList this$0; > > > > Crosscompilation to Objective C works fine and yields two files, each > > having the line > > > > @public packagename_AbstractList_* this$0; > > > > but because one class extends the other, I get this error from gcc: > > > > error: duplicate member 'this$0'; > > > > One option would be to change my Java code, but the Collections > > Framework has at least 4 Classes with multiple (even more than two) > > inner classes which inherit from each other. So I guess this case > should > > somehow be handled by the XMLVM crosscompiler, but I'm completely > unsure > > how this would be done. When emitting the interface in > xmlvm2objc.xsl, > > we would need to check if there is any superclass which is also > an inner > > class, thus having a this$0 field. I think this might be beyond the > > complexity of what should be done here, isn't it? > > > > Im happy about any advice. > > > > With best regards, > > Brian > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > > trial. Simplify your report design, integration and deployment - > and focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > xmlvm-users mailing list > > xml...@li... > <mailto:xml...@li...> > > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > xmlvm-users mailing list > xml...@li... > <mailto:xml...@li...> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > |