From: William S F. <ws...@fu...> - 2016-02-10 21:56:38
|
I've been working on this over the last few days. My goal is to get something useful soon (days rather than weeks). I also think this should be turned on via typemaps/features and not automatic in the near term. If we can get good code using this manual approach, we can start think about turning it on automatically for say swig-3.1. My focus is on only concrete classes in the inheritance hierarchy and I havn't had to radically change Vladimir's original approach too much to achieve that. Perhaps you can focus on fixing the current state for supporting pure abstract base classes as that is your interest? Although longer term the generated code needs to be customisable (too much is hard coded), I'd like to work on getting the correct code generated in the short term. I've pushed my modifications to a branch called interfaces: https://github.com/swig/swig/tree/interfaces I havn't tried to track down other changes in Vladimir's https://github.com/wkalinin/swig/tree/devel. I think most of your points are roughly working in the branch via the DECLARE_INTERFACE_RENAME macro, although I don't exactly understand all of them. What I suggest is for you to take a look at the generated code in the branch and discuss what you think should change and is incorrect in the two test-cases: multiple_inheritance_abstract and multiple_inheritance_interfaces. These examples need expanding with further use cases, in particular true abstract base classes and more multiple inheritance. For the record, I don't envisage supporting virtual inheritance. I havn't thought about directors and think we should solve non-directors first. I am mostly happy with the inheritance hierarchy that is generated as the multiple_inheritance_interfaces testcase. Although am undecided whether K should be: public class K implements IK { ... } instead of: public class K implements IJ, IK { ... } similarly perhaps L and M should only implement IL ?? William On 10 February 2016 at 16:20, Paul Donohue <sw...@pa...> wrote: > I'm not sure what your timeline is here, but I too have a need to get multiple inheritance support working, and a couple months ago I spent a bunch of time analyzing Vladamir's changes and thinking through various use cases. I conceptually broke the problem up into a series of smaller changes, which I then started documenting and implementing (based loosely on Vladamir's changes, but with various significant improvements). Unfortunately, other priorities interrupted my work, so both my documentation and implementation are still incomplete and rather messy. However, if it would help you, I can try to revisit this over the next few days and see if I can't finish some of it. (I intended to pick this project back up soon anyway.) > > Basically, the series of changes is: > 1) Allow access to base class members without explicit C++ upcasts by copying the members of any base class that is skipped by the language module (due to a lack of support for multiple inheritance) to the derived class. > 2) Add target language support for implicit upcasts to abstract base classes by: > 2a) Converting abstract base classes into interfaces in the target language > 2b) Generating additional proxy classes that implement each interface so that base class objects returned by C++ functions can be returned in the target language. > 2c) Automatically detecting abstract base classes and enabling 2a and 2b when appropriate. > 3) Add support for multiple concrete base classes by: > 3a) Exposing the base proxy classes generated by #2 so they can be instantiated directly. > 3b) Adjusting swig so that generated functions in the target language which return the base class will explicitly return the base proxy class in the target language (rather than returning a base proxy class object that is cast to the associated interface in the target language), but generated functions in the target language which accept the base class as an argument will still use the interface rather than the base proxy class as the argument type so that both concrete base objects and derived objects can be passed in. (This would be optional behavior that could be selectively enabled/disabled depending on the use case.) > 4) Assorted minor tweaks to ensure that downcasts in the target language work as expected by default and to enable some use of directors with multiple inheritance. (I had several ideas here, but I hadn't figured out all of the use cases for this yet, so I hadn't decided whether any of these ideas actually made sense and were worth implementing.) > > -Paul > > On Fri, Feb 05, 2016 at 01:39:26AM +0300, Vladimir Kalinin wrote: >> Hi William, >> >> I tried to merge the missing changes from 'devel' to 'interfaces' and >> failed. I will attempt to apply interface related changes to the >> master instead, but not today already. >> >> As for analyzing the changes, there are effectively 2 sets of changes >> in 'devel', differentiating it from 'swig/master'. These are merges >> from 'vadz/doxygen' branch, with my C# comments translation added, and >> feature_interface implementation. So you can just compare >> Modules/csharp.cxx and Modules/java.cxx with their 'swig/master' >> counterparts, and disregard all the changes starting with any string >> containing "doxygen". >> (There is also L"" literals support not merged to master, >> but is does not affect charp.cxx or java.cxx) >> I understand that the history looks messy, but that is mostly a result >> of multiple merges from/to the master branch. >> >> Best regards, >> Vladimir mailto:VKa...@op... >> >> -----Original Message----- >> Hi Vladimir >> >> I don't really want to have to analyse your main branch and pull out >> these specific changes. You could help by using some of the git diff >> commands comparing to whatever version you branched off to pull out >> the interface specific changes. Then add them onto your interfaces >> branch or setup a new branch from latest master. In the meantime, I'm >> getting familiar with what you've done on that branch. >> >> William >> >> >> On 4 February 2016 at 19:24, Vladimir Kalinin <vka...@op...> wrote: >> > Hi William, >> > >> > The actual version we are using locally is here: https://github.com/wkalinin/swig/tree/devel >> > Unfortunately I don't remember if all the changes from it were merged >> > in the "interfaces" branch (probably not). I effectively stopped working on that >> > feature because in its current state it works for us, but to make it >> > really universal requires much more work than is already done, and I >> > can't afford it atm. >> > If you are intending to make it acceptable for the merge in the trunk >> > that would be wonderful, because we won't have to support the branched >> > version of swig internally, and I'll be glad to help you in that work. >> > >> > I added a set of helper definitions to make feature usage easier: >> > https://github.com/wkalinin/swig/tree/devel/Lib/csharp/feature_interface.i >> > The most used macro "DECLARE_INTERFACE_RENAME" is named somewhat >> > confusingly, but I don't know how to name it better. >> > >> > Best regards, >> > Vladimir mailto:VKa...@op... >> > >> > -----Original Message----- >> > Hi Vladimir >> > >> > I need to get some multiple inheritance support working fairly quickly >> > and was thinking of using this as a starting point. This is quite an >> > old email chain, but is >> > https://github.com/wkalinin/swig/tree/interfaces the latest you have >> > on this? If not, can you describe what else has changed and add on any >> > additions you'd like to keep into this branch in your repo and I'll >> > use this as a base for improvements? >> > >> > Thanks >> > William >> > >> > >> > On 12 July 2013 at 22:42, William S Fulton <ws...@fu...> wrote: >> >> Vladimir, for C#, yes I would like to minimise the number of files and >> >> filename clashes and keep the code for a proxy class together in one place >> >> so it is less scattered about and a bit more consistent with the new Java >> >> approach of putting the same code in the one file. >> >> >> >> Thanks for putting in the changes when you get a chance. >> >> >> >> William >> >> >> >> >> >> On 08/07/13 14:41, Vladimir Kalinin wrote: >> >>> >> >>> Hiding the implementation class within the Java interface is a good idea. >> >>> I'll implement it as soon as I'll have time. (perhaps at the end of the >> >>> month; unfortunately, I'm quite busy right now.) >> >>> >> >>> It is impossible to completely hide the implementation class from >> >>> the user, because if the user wants to implement the interface on the >> >>> Java/C# side he will need to aggregate the implementation class, >> >>> to have a valid underlying C++ class for the interface. >> >>> >> >>> Non-const ref appeared in the typemaps because in our project some >> >>> interface was returned via non-const reference. Anyway, typemaps are >> >>> customizable, we'll just use the modified version if the standard will >> >>> be changed. >> >>> >> >>> Moving C# implementation class in a separate namespace gives no >> >>> benefit regarding name space pollution - this namespace >> >>> should have a unique name anyway. It is possible to move it in the >> >>> same file of course (can't see why does it matter though - to minimize >> >>> the number of files?). >> >>> >> >>> ----- Original Message ----- >> >>> I've taken another look at the implementation. My opinions were mostly >> >>> based on having this SWIGTYPE_xxx class exposed to the user. It looks >> >>> like that is not the intention and what I see is just a bug. >> >>> >> >>> The typemaps in feature_java.i need to be changed for non-const ref, >> >>> otherwise the SWIGTYPE_xxx classes appear in the API that a user will see. >> >>> >> >>> With this change, the approach is much better. The SWIGTYPE_xxx classes >> >>> become an implementation detail which I think is quite acceptable. >> >>> >> >>> I've a suggestion to improve further. First lets give these SWIGTYPE_xxx >> >>> classes a name, say Interface Proxy classes. For Java, let's rename all >> >>> these classes and call them all SwigInterfaceProxy and push them into >> >>> the actual interface as an inner class. So for example, if we have: >> >>> >> >>> %include "feature_interface.i" >> >>> DECLARE_INTERFACE_RENAME(IA, IA, SWIGTYPE_IA) >> >>> >> >>> struct IA { >> >>> virtual void a() = 0; >> >>> virtual ~IA() {} >> >>> }; >> >>> >> >>> IA.java is the only proxy file class generated and SWIGYPE_IA simply >> >>> moves into the IA interface: >> >>> >> >>> public interface IA { >> >>> long IA_getCPtr(); >> >>> void a(); >> >>> >> >>> public class SWIGTYPE_IA implements IA { >> >>> private long swigCPtr; >> >>> protected boolean swigCMemOwn; >> >>> >> >>> public SWIGTYPE_IA(long cPtr, boolean cMemoryOwn) { >> >>> swigCMemOwn = cMemoryOwn; >> >>> swigCPtr = cPtr; >> >>> } >> >>> >> >>> protected static long getCPtr(SWIGTYPE_IA obj) { >> >>> return (obj == null) ? 0 : obj.swigCPtr; >> >>> } >> >>> >> >>> protected void finalize() { >> >>> delete(); >> >>> } >> >>> >> >>> public synchronized void delete() { >> >>> if (swigCPtr != 0) { >> >>> if (swigCMemOwn) { >> >>> swigCMemOwn = false; >> >>> exampleJNI.delete_SWIGTYPE_IA(swigCPtr); >> >>> } >> >>> swigCPtr = 0; >> >>> } >> >>> } >> >>> public long IA_getCPtr(){ return >> >>> exampleJNI.SWIGTYPE_IA_IA_getCPtr(swigCPtr); } >> >>> >> >>> public void a() { >> >>> exampleJNI.SWIGTYPE_IA_a(swigCPtr); >> >>> } >> >>> >> >>> } >> >>> } >> >>> >> >>> but then go one step further and rename SWIGTYPE_IA to >> >>> SwigInterfaceProxy. That is the inner class has the same name for all >> >>> classes that use the 'interface' feature. >> >>> >> >>> I think using the same name, ie, SwigInterfaceProxy, makes the generated >> >>> code easier to read/comprehend. >> >>> >> >>> C# doesn't accept inner classes within an interface. I'd like to see the >> >>> Interface Proxy generated into the IA.cs file still, so how about >> >>> something along the lines of generating it into a different namespace in >> >>> IA.cs? >> >>> >> >>> Any thoughts or further refinements? >> >>> >> >>> William >> >>> >> >>> On 18/06/13 20:57, Vladimir Kalinin wrote: >> >>>> >> >>>> Hi William, >> >>>> >> >>>> The point is to reflect multiple inheritance. All that you say is >> >>>> true, but what alternative can you suggest? >> >>>> If you don't have multiple inheritance, clearly you don't need >> >>>> interfaces. >> >>>> >> >>>> Anyway, this feature is useful in our project even if will not be >> >>>> useful for anyone else, so I'll just keep it in my branch. >> >>>> >> >>>> Best regards, >> >>>> Vladimir mailto:vka...@op... >> >>>> >> >>>> ----- Original Message ----- >> >>>> Hi Kalinin >> >>>> >> >>>> I've just been looking at the interface implementation. I know I >> >>>> originally suggested we develop this, but given the restrictions of the >> >>>> design I am now wondering what the point is! Here is some analysis and >> >>>> thoughts: >> >>>> >> >>>> - The target language interface replaces the target language proxy >> >>>> class, however, a proxy class is still really needed. It is needed to >> >>>> hold the underlying c++ pointer, although the implementation sort of >> >>>> tries to avoid this by making a call into c++ from the target language >> >>>> which has a performance hit compared to holding the pointer on the >> >>>> target language side. With this approach the proxy class can be avoided >> >>>> in some uncommon circumstances but the SWIGTYPE_xxx classes need to be >> >>>> generated to provide the functionality of the removed proxy class. >> >>>> - The implementation requires that each class in an inheritance chain to >> >>>> repeat the 'implements' (inheritance) from the interface... this is not >> >>>> normal. There is no one-to-one mapping made onto the designed C++ >> >>>> inheritance chain, rather confusing and weird. >> >>>> - There is too much code coming from Swig that is not controllable by >> >>>> users, eg all of the SWIGTYPE_xxx classes... typemaps can't change this >> >>>> code because it is a non-existent C++ type. This could be overcome >> >>>> though by adding in yet more features (complexity). >> >>>> - Having an interface ABC and a SWIGTYPE_ABC is messy in my point of >> >>>> view. >> >>>> >> >>>> My current thinking is because the SWIGTYPE_xxx proxy classes are still >> >>>> needed, all that has happened is the generated code is more confusing >> >>>> without any gain, in fact there is a performance hit. >> >>>> >> >>>> Brant, you mentioned two types of interfaces, where developers need to >> >>>> know which methods to implement. If you are deriving from the proxy >> >>>> classes, then I presume you are using directors? >> >>>> >> >>>> I'm not entirely sure what the best way forward is, but I suspect the >> >>>> only way to have normal interfaces is to turn it on only for directors. >> >>>> Has anyone looked at that? Maybe I've missed something... what are the >> >>>> use cases (not using directors) that are useful with the current >> >>>> implementation of the feature as it stands? >> >>>> >> >>>> William >> >>>> >> >>>> On 29/05/13 15:18, Vladimir Kalinin wrote: >> >>>>> >> >>>>> I "solved" the non-abstract method problem recently and ported >> >>>>> the final implementation to Java. >> >>>>> (see https://github.com/wkalinin/swig/tree/interfaces >> >>>>> there is also a separate branch with all my patches merged: >> >>>>> https://github.com/wkalinin/swig/tree/devel (with nested classes, etc.) >> >>>>> This is what I myself use in production, so the first version may >> >>>>> contain some merge bugs - it was used only in test environment) >> >>>>> >> >>>>> There are still some limitations in complex cases (e.g. when one >> >>>>> interface >> >>>>> is inherited several times via different inheritance paths - it requires >> >>>>> generating >> >>>>> corresponding "feature:action" for C++ proxy methods, to make the >> >>>>> calls via correct upcast chain), >> >>>>> but I personally did not yet met these cases in practice and consider >> >>>>> then non-priority. >> >>>>> >> >>>>> ----- Original Message ----- >> >>>>> My project has two types of classes that contain pure virtual methods. >> >>>>> The first is similar to your case, where the class only contains pure >> >>>>> virtual methods. In this case, the desired result it to have swig >> >>>>> generate a C# or Java interface. The second case is classes that contain >> >>>>> a mixture of pure virtual methods and non-virtual methods. For this >> >>>>> second case, the desired result is for swig to generate an abstract C# >> >>>>> or Java class where the pure virtual methods are abstract. >> >>>>> >> >>>>> Currently, swig generates a C# and Java class with non-abstract methods >> >>>>> for the pure virtual methods. This creates confusion to developers >> >>>>> implementing the methods in the target language and causes runtime >> >>>>> errors when they fail to implement all of the methods. >> >>>>> >> >>>>> Brant >> >>>>> >> >>>>> On 5/16/13 10:39 AM, Vladimir Kalinin wrote: >> >>>>>> >> >>>>>> Hi Brant, >> >>>>>> >> >>>>>> No, I didn't work on this project recently. You see - for my >> >>>>>> applications it is enough to convert to interfaces C++ classes >> >>>>>> containing only pure virtual functions and no data members. >> >>>>>> Converting to interfaces the classes with data members and non-pure >> >>>>>> virtual >> >>>>>> member functions is a lot more complicated, especially when/if virtual >> >>>>>> inheritance is used. I definitely intend to finish this work (if no >> >>>>>> one else will volunteer to do it), but I can't make any promises about >> >>>>>> timing. >> >>>>>> >> >>>>>> BTW, what do you think about the questions discussed in the previous >> >>>>>> mail? >> >>>>>> >> >>>>>> Best regards, >> >>>>>> Vladimir mailto:vka...@op... >> >>>>>> >> >>>>>> ----- Original Message ----- >> >>>>>> 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 >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> ------------------------------------------------------------------------------ >> >>>>>> AlienVault Unified Security Management (USM) platform delivers complete >> >>>>>> security visibility with the essential security capabilities. Easily >> >>>>>> and >> >>>>>> efficiently configure, manage, and operate all of your security >> >>>>>> controls >> >>>>>> from a single console and one unified framework. Download a free trial. >> >>>>>> http://p.sf.net/sfu/alienvault_d2d >> >>>>>> _______________________________________________ >> >>>>>> Swig-devel mailing list >> >>>>>> Swi...@li... >> >>>>>> https://lists.sourceforge.net/lists/listinfo/swig-devel >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> ------------------------------------------------------------------------------ >> >>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> >>>>> Get 100% visibility into your production application - at no cost. >> >>>>> Code-level diagnostics for performance bottlenecks with <2% overhead >> >>>>> Download for free and get started troubleshooting in minutes. >> >>>>> http://p.sf.net/sfu/appdyn_d2d_ap1 >> >>>>> _______________________________________________ >> >>>>> Swig-devel mailing list >> >>>>> Swi...@li... >> >>>>> https://lists.sourceforge.net/lists/listinfo/swig-devel >> >>>>> >> >>>> >> >>>> . >> >>>> >> >>> >> >>> >> >> >> > >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> |