Re: [Swig-user] javacode re-use and typemap matching

[Eric N. <ni...@pa...>]

William S Fulton wrote:
> Eric Nickell wrote:
>   
>> William S Fulton wrote:
>>     
>>> Eric Nickell wrote:
>>>  
>>>       
>>>> Following the example in the "SWIG and Java" section of the swig
>>>> docs, I'm trying to add some basic functionality to all the
>>>> swig-generated proxy classes. But for some of these proxy classes, I
>>>> need to add other functionality as well. So I end up with something
>>>> of the form:
>>>>
>>>> %typemap(javabase) SWIGTYPE, SWIGTYPE *, SWIGTYPE &, SWIGTYPE [],
>>>> SWIGTYPE (CLASS::*) "SWIG"
>>>>
>>>> %typemap(javacode) SWIGTYPE, SWIGTYPE *, SWIGTYPE &, SWIGTYPE [],
>>>> SWIGTYPE (CLASS::*) %{
>>>>     protected long getPointer() {
>>>>         return swigCPtr;
>>>>     }
>>>> %}
>>>>
>>>> %typemap(javacode) struct BananaPhoneInfo %{
>>>>     public int hashCode() {
>>>>        return getPointer();
>>>>     end
>>>> %}
>>>>
>>>>
>>>> Of course, this doesn't work, because the 2nd typemap(javacode) sets
>>>> the typemap for the more narrowly defined match, occluding rather
>>>> than augmenting the first typemap(javacode).
>>>>
>>>> Is there a means in the "typemap(javacode) struct BananaPhoneInfo" to
>>>> have swig include the text of the wider match as well?
>>>>
>>>>     
>>>>         
>>> Yes this is a nuisance which I will resolve in a future release. For
>>> now, the best thing is to use some macros to stitch together all the
>>> bits that you want. Note that in order for the preprocessor to expand
>>> your macros, you need to use {...} braces for the typemap and specify
>>> noblock=1 to remove them, as the %{ ... %} braces are not processed by
>>> the preprocessor, for example:
>>>
>>> %define GENERIC_EXTRA_CODE
>>>     protected long getPointer() {
>>>         return swigCPtr;
>>>     }
>>> %enddef
>>>
>>> %typemap(javacode, noblock=1) SWIGTYPE, SWIGTYPE *, SWIGTYPE &, SWIGTYPE
>>> [], SWIGTYPE (CLASS::*)
>>> {
>>>   GENERIC_EXTRA_CODE
>>> }
>>>
>>> %typemap(javacode, noblock=1) struct BananaPhoneInfo {
>>>   GENERIC_EXTRA_CODE
>>>     public int hashCode() {
>>>        return getPointer();
>>>     }
>>> }
>>>
>>> But unfortunately you get some preprocessor comments in the generated
>>> code. The other thing to try is:
>>>
>>> %typemap(javacode) SWIGTYPE, SWIGTYPE *, SWIGTYPE &, SWIGTYPE [],
>>> SWIGTYPE (CLASS::*)
>>> %{
>>>   protected long getPointer() {
>>>       return swigCPtr;
>>>   }
>>> %}
>>>
>>> %define ADD_HASH_CODE(CTYPE...)
>>> %typemap(javacode) CTYPE %{
>>>   protected long getPointer() {
>>>       return swigCPtr;
>>>   }
>>>   public int hashCode() {
>>>      return getPointer();
>>>   }
>>> %}
>>> %enddef
>>>
>>> ADD_HASH_CODE(struct BananaPhoneInfo)
>>> ADD_HASH_CODE(struct ApplePhoneInfo)
>>> ADD_HASH_CODE(struct PearPhoneInfo)
>>> ... etc.
>>>
>>>
>>> William
>>>   
>>>       
>> The 1st technique doesn't seem to work because of swig forcing insertion
>> of a wrapping { } block, which is not allow for declaring methods as
>> part of a class.
>>
>> Since most of the BananaPhone stuff is struct-specific %extends, it's
>> probably just easier for now to replicate the boilerplate code into each
>> one of those.
>>
>>     
>
> The first technique does work as explained because of the noblock attribute.
>
> William
>   
Missed that. Thanks.