|
From: Arno P. <ar...@pu...> - 2009-09-09 17:53:25
|
Brian,
I just committed a patch that should hopefully fix the bug you've
encountered. Basically I generate getter/setter methods for instance
members and use name mangling for the declaration of the instance member
to avoid naming conflict.
Give it a try and let me know if this works now.
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
>
>
|