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

[Arno P. <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