From: Brant K. K. <bk...@tr...> - 2013-05-16 15:28:49
|
I am interested in using this feature in my project. Has there been any movement in getting this merged into swig? Once this is working in the C# module, I would also be interested in porting it over to the Java module. Brant On 4/21/13 1:14 PM, Vladimir Kalinin wrote: > Hi William, > > Thanks for the test, I quite forgot about it. It revealed a case > that I didn't think about. Consider the following scenario: > %feature ("interface") Base2; > struct Base1 { virtual void f1(){}}; > struct Base2 { virtual void f2(){}}; > struct Descendant : Base1, Base2 {}; > > Note that Base2::f2() function is not abstract, and when Base2 is > converted to interface, Base2::f2() implementation should be injected > to the "Descendant" proxy class (probably using "extend"). > (I didn't consider this case because in our project abstract base > classes are very like C#/Java interfaces and never contain > implementations, but anyway, this case is quite feasible.) > > What do you think about "extend"? I can't really say when it > should be injected. The simplest place is the parser, but I didn't want to > touch the parser with these language specific changes. > The only other solution I can think > about is copying function's parse tree nodes from the "interfaces" to > the descendant classes, marking them with some runtime attribute, so > that proper "upcast" pointer would be used for them instead of > swigPtr. This can be done in the language module at the start of the > class handler. > > Any other suggestions? > > BTW, I didn't find any traces of the solution of that problem in ZhiYang's > code. > > -----Original Message----- > Hi Vladimir > > Great news, although I'm finding it hard to understand what is > implemented without applying the patch. I'd like to see proper > interfaces, that is simple ABCs, working first and possibly you haven't > addressed this yet? The test in > http://thread.gmane.org/gmane.comp.programming.swig.devel/18403 is what > I originally asked Zhiyang to focus on first. I would like to see this > test added to your github fork and can you write the C# equivalent to > the Java runtime test so I can more easily see what state it is in? > > BTW, I havn't forgotten about your wonderful nested class work, I just > need to find some more time to take a good look and will do so once > 2.0.10 is out the door. > > William > > On 16/04/13 21:10, Vladimir Kalinin wrote: >> I finally found some time to implement this feature (only for C# for now) >> You may look at it here: https://github.com/wkalinin/swig/tree/interfaces >> >> It works as a combination of a feature and a set of typemaps. >> Here are 2 versions of the typemaps, w/o namespaces and with them >> >> %define DECLARE_INTERFACE(CTYPE, INTERFACE, IMPL) >> %rename (IMPL) CTYPE; >> %feature("interface", name = "INTERFACE", cptr = "GetCPtr") CTYPE; >> %typemap(cstype) CTYPE*, const CTYPE& "INTERFACE" >> %typemap(csdirectorout) CTYPE*, const CTYPE& "$cscall.GetCPtr()" >> %typemap(csdirectorin) CTYPE*, const CTYPE& >> %{ >> (INTERFACE)new IMPL($iminput,false) >> %} >> %typemap(csin) CTYPE*, const CTYPE& "$csinput.GetCPtr()" >> %typemap(csout, excode=SWIGEXCODE) CTYPE*, const CTYPE& >> { >> IMPL ret = new IMPL($imcall,true); >> $excode >> return (INTERFACE)ret; >> } >> %enddef >> >> %define DECLARE_INTERFACE_NS(CTYPE, INTERFACE, IMPL, NAMESPACE) >> %rename (IMPL) CTYPE; >> %feature("interface", name = "INTERFACE", cptr = "GetCPtr") CTYPE; >> %typemap(cstype) CTYPE*, const CTYPE& "NAMESPACE.INTERFACE" >> %typemap(csdirectorout) CTYPE*, const CTYPE& "$cscall.GetCPtr()" >> %typemap(csdirectorin) CTYPE*, const CTYPE& >> %{ >> (NAMESPACE.INTERFACE)new NAMESPACE.IMPL($iminput,false) >> %} >> %typemap(csin) CTYPE*, const CTYPE& "$csinput.GetCPtr()" >> %typemap(csout, excode=SWIGEXCODE) CTYPE*, const CTYPE& >> { >> NAMESPACE.IMPL ret = new NAMESPACE.IMPL($imcall,true); >> $excode >> return (NAMESPACE.INTERFACE)ret; >> } >> %enddef >> >> %rename is optionally used if implementation class should be named >> differently from the original class. >> These macros are more of a sample/illustration, because e.g. in our >> project we use quite different typemaps to implement proper >> downcast behaviour. >> >> I attached the sample file I used for testing. >> >> -----Original Message----- >> I suppose that's true for Java, but in C# you could use the same name in all the interfaces, I think, thanks to explicit interface implementation: >> >> interface IA { IntPtr getCPtr(); } >> interface IB : IA { IntPtr getCPtr(); } >> interface IC { IntPtr getCPtr(); } >> class Foo : IA, IB, IC { >> ... >> IntPtr IA.getCPtr() { return ???; } >> IntPtr IB.getCPtr() { return ???; } >> IntPtr IC.getCPtr() { return ???; } >> } >> >> Foo foo = ...; >> IntPtr aPtr = ((IA)foo).getCPtr(); >> >> Explicit interface implementations have the advantage that they are less visible (interface methods are always public, technically, but they are invisible on an object of type "Foo" until you cast to IA or IB or IC.) >> >> Note that since these methods are public, there is greater reason to make it possible to rename them (it is very annoying that opaque pointers are hardcoded with the name SWIGTYPE_p_Xyz, so I %ignore everything that would cause an opaque pointer to be produced, or map opaque pointers to IntPtr instead, through typemaps.) >> >> >> >> From: Vladimir Kalinin <vka...@op...> >> To: David Piepgrass <Dav...@tr...> >> Cc: <swi...@li...> >> Date: 03/22/2013 01:25 PM >> Subject: Re: [Swig-devel] Abstract base classes to interfaces conversion >> >> >> >> >> Thinking some more about the subject, it turns out that the only reliable way to obtain valid C pointer from the interface is to extend the interface with the corresponding function (like "internal IntPtr getCPtr();" ). >> It cannot be called just getCPtr(), because if some class implements several interfaces, it has to implement several "getCPtr" functions. Interface name may be appended|prepended to the function name to distinguish them. >> Implementation of these functions is the same as that of SwigUPCAST() >> >> -----Original Message----- >> I have one suggestion about interface support, if you implement this feature: it should be possible to wrap a class with BOTH a normal wrapper AND an interface. That is, don't limit interfaces to abstract base classes--also allow non-abstract base classes. For example, given a class hierarchy like: >> >> struct A { int a; void fa(); } >> struct B { int b; void fb(); } >> struct C : A, B { int c; void fc(); } >> >> It should be possible to create an interface "IB" in C#: >> >> public interface IB { >> int b { get; set; } >> void fb(); >> } >> >> But also a concrete class "B" that implements IB: >> >> public class B : IB { >> public B(...) {...} >> public int b { get { ... } set { ... } } >> public void fb() { ... } >> ... >> } >> >> And then the wrapper for C would be: >> >> public class C : A, IB { >> public C(...) {...} >> public int b { get { ... } set { ... } } >> public void fb() { ... } >> public int c { get { ... } set { ... } } >> public void fc() { ... } >> ... >> } >> >> This way, it is possible to create a standalone B that is not a C. Of course, if B is an abstract base class then an interface alone should suffice, i.e. only an interface IB is needed, not a class B. >> >> It would also be nice if there were some way to request SWIG to create a property that returns a wrapper for B, e.g. in C#, C could have an operator for this: >> >> // C can convert to B implicitly >> public static implicit operator B(C c) { ??? } >> >> But this feature is optional, since the user could add the necessary code manually, or (I assume) with help from a macro. >> >> >> >> >> From: Vladimir Kalinin <vka...@op...> >> To: <swi...@li...> >> Date: 03/19/2013 04:55 PM >> Subject: [Swig-devel] Abstract base classes to interfaces conversion >> >> >> >> >> >> As far as I know, currently there is no easy way to convert C++ abstract base >> classes to Java/C# interfaces. (short of redeclaring the classes and >> doing some more work) >> >> I found the only reference to the attempt to implement that feature >> here: http://thread.gmane.org/gmane.comp.programming.swig.devel/18403 >> Is there any information about the status of that work? >> (As I understand, the patch posted in that thread is far from >> perfection) >> >> Maybe there is some alternative solution being worked at in some SWIG branch? >> >> If no one is planning to implement that feature in near future, I >> will do it (in some way at least). >> (Because, converting abstract base classes to interfaces is >> currently the most time consuming feature in our >> project wrappers (after nested classes were implemented)). >> >> I think "feature:interface" syntax proposed by Zhiyang Jiang is ok. >> >> Any suggestions, advices? >> >> >> ------------------------------------------------------------------------------ >> >> >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> >> >> >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2241 / Virus Database: 3162/5756 - Release Date: 04/19/13 > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |