Re: [xmlvm-users] Multiple inner classes inheriting from each other lead to a gcc error.

[Brian S. <bri...@go...>]

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...>

>
> 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...
> > 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...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>