xmlvm-users

[xmlvm-users] Optional Methods in C-Backend

[Markus H. <ma...@ti...>]

Hi,

I'd like to use a UITableViewDelegate with the C Backend. Some methods in that class are optional. XMLVM generates stubs for the, that throw the XMLVM_NOT_IMPLEMENTED Error:

JAVA_FLOAT org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath(JAVA_OBJECT me, JAVA_OBJECT n1, JAVA_OBJECT n2)
{
    //XMLVM_BEGIN_WRAPPER[org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath]
    XMLVM_NOT_IMPLEMENTED();
    //XMLVM_END_WRAPPER
}

I can override all of the methods, of course, but I rather would leave them out. What would be the correct way to handle optional methods?

Markus

Re: [xmlvm-users] Optional Methods in C-Backend

[Panayotis K. <pan...@pa...>]

On 05 Μαϊ 2011, at 11:35 π.μ., Markus Heberling wrote:

> Hi,
> 
> I'd like to use a UITableViewDelegate with the C Backend. Some methods in that class are optional. XMLVM generates stubs for the, that throw the XMLVM_NOT_IMPLEMENTED Error:
> 
> JAVA_FLOAT org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath(JAVA_OBJECT me, JAVA_OBJECT n1, JAVA_OBJECT n2)
> {
>     //XMLVM_BEGIN_WRAPPER[org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath]
>     XMLVM_NOT_IMPLEMENTED();
>     //XMLVM_END_WRAPPER
> }
> 
> I can override all of the methods, of course, but I rather would leave them out. What would be the correct way to handle optional methods?
> 
> Markus

I can't help you with the C backend, but I'll describe a bit what I did in the same case with the ObjC backend, so that the C Gurus here could advise the correct answer.

The problem is, there is no "default" value for these (and all similar) methods. Moreover, the iOS would behave different, when these methods are present, and do something else, when these methods are missing. 

What I did on the ObjC backend was to do something similar to what (I believe) Apple does.
First of all, *all* ObjC delegate methods exist and all point to their Java counterpart.
Then the method that answers to the ObjC runtime if this method exists (i.e. respondsToSelector) is overridden. If an actual Java-based implementation exists, then respondsToSelector responds that the actual ObjC delegate selector exists (although the ObjC selector *always* exist). If it doesn't then it replies that this method does not exist.

WIth such a trick it is possible to properly inform the UITableView that an optional *Java* method exist, and have the desired/correct behavior.

Re: [xmlvm-users] Optional Methods in C-Backend

[Arno P. <ar...@pu...>]

On 5/5/11 6:30 AM, Panayotis Katsaloulis wrote:
>
> On 05 Μαϊ 2011, at 11:35 π.μ., Markus Heberling wrote:
>
>> Hi,
>>
>> I'd like to use a UITableViewDelegate with the C Backend. Some methods
>> in that class are optional. XMLVM generates stubs for the, that throw
>> the XMLVM_NOT_IMPLEMENTED Error:
>>
>> JAVA_FLOAT
>> org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath(JAVA_OBJECT
>> me, JAVA_OBJECT n1, JAVA_OBJECT n2)
>> {
>> //XMLVM_BEGIN_WRAPPER[org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath]
>> XMLVM_NOT_IMPLEMENTED();
>> //XMLVM_END_WRAPPER
>> }
>>
>> I can override all of the methods, of course, but I rather would leave
>> them out. What would be the correct way to handle optional methods?
>>
>> Markus
>
> I can't help you with the C backend, but I'll describe a bit what I did
> in the same case with the ObjC backend, so that the C Gurus here could
> advise the correct answer.
>
> The problem is, there is no "default" value for these (and all similar)
> methods. Moreover, the iOS would behave different, when these methods
> are present, and do something else, when these methods are missing.
>
> What I did on the ObjC backend was to do something similar to what (I
> believe) Apple does.
> First of all, *all* ObjC delegate methods exist and all point to their
> Java counterpart.
> Then the method that answers to the ObjC runtime if this method exists
> (i.e. respondsToSelector) is overridden. If an actual Java-based
> implementation exists, then respondsToSelector responds that the actual
> ObjC delegate selector exists (although the ObjC selector *always*
> exist). If it doesn't then it replies that this method does not exist.
>
> WIth such a trick it is possible to properly inform the UITableView that
> an optional *Java* method exist, and have the desired/correct behavior.

You can do the same with the C backend. The key is to implement 
respondsToSelector in UITableViewDelegate in such a way that it figures 
out if a Java method has been overridden or not. This can easily be done 
with the help of the vtable: if a method is overridden in a derived 
class, the vtable entry for that method will point to the implementation 
in the derived class. If the method has not been overridden, the vtable 
entry will still point to the implementation of the base class. The same 
trick is used in org_xmlvm_iphone_UIResponder.m (for the C backend) to 
check if methods such as touchesBegan: have been overridden. Here the 
relevant code sniplet from that file:

     VTABLE_PTR func = 
thiz->tib->vtable[XMLVM_VTABLE_IDX_org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent];
     if (func == (VTABLE_PTR) 
org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent) 
{
         // vtable index for this method still points to the 
implementation of
         // class UIResponder. Delegate event to the next responder
		[[self nextResponder] touchesBegan:touches withEvent:event];

If the if-condition is true, the method has not been overridden.

Hope this helps,
Arno

Re: [xmlvm-users] Optional Methods in C-Backend

[Markus H. <ma...@ti...>]

Hi.

shouldn't this be done automagically by xmlvm?

Like adding an @Optional annotation, that can be put on optional methods in java classes, and xmlvm will generate the correct respondsToSelector?


Regards,
Markus

Am 05.05.2011 um 18:19 schrieb Arno Puder:

> 
> 
> On 5/5/11 6:30 AM, Panayotis Katsaloulis wrote:
>> 
>> On 05 Μαϊ 2011, at 11:35 π.μ., Markus Heberling wrote:
>> 
>>> Hi,
>>> 
>>> I'd like to use a UITableViewDelegate with the C Backend. Some methods
>>> in that class are optional. XMLVM generates stubs for the, that throw
>>> the XMLVM_NOT_IMPLEMENTED Error:
>>> 
>>> JAVA_FLOAT
>>> org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath(JAVA_OBJECT
>>> me, JAVA_OBJECT n1, JAVA_OBJECT n2)
>>> {
>>> //XMLVM_BEGIN_WRAPPER[org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath]
>>> XMLVM_NOT_IMPLEMENTED();
>>> //XMLVM_END_WRAPPER
>>> }
>>> 
>>> I can override all of the methods, of course, but I rather would leave
>>> them out. What would be the correct way to handle optional methods?
>>> 
>>> Markus
>> 
>> I can't help you with the C backend, but I'll describe a bit what I did
>> in the same case with the ObjC backend, so that the C Gurus here could
>> advise the correct answer.
>> 
>> The problem is, there is no "default" value for these (and all similar)
>> methods. Moreover, the iOS would behave different, when these methods
>> are present, and do something else, when these methods are missing.
>> 
>> What I did on the ObjC backend was to do something similar to what (I
>> believe) Apple does.
>> First of all, *all* ObjC delegate methods exist and all point to their
>> Java counterpart.
>> Then the method that answers to the ObjC runtime if this method exists
>> (i.e. respondsToSelector) is overridden. If an actual Java-based
>> implementation exists, then respondsToSelector responds that the actual
>> ObjC delegate selector exists (although the ObjC selector *always*
>> exist). If it doesn't then it replies that this method does not exist.
>> 
>> WIth such a trick it is possible to properly inform the UITableView that
>> an optional *Java* method exist, and have the desired/correct behavior.
> 
> You can do the same with the C backend. The key is to implement 
> respondsToSelector in UITableViewDelegate in such a way that it figures 
> out if a Java method has been overridden or not. This can easily be done 
> with the help of the vtable: if a method is overridden in a derived 
> class, the vtable entry for that method will point to the implementation 
> in the derived class. If the method has not been overridden, the vtable 
> entry will still point to the implementation of the base class. The same 
> trick is used in org_xmlvm_iphone_UIResponder.m (for the C backend) to 
> check if methods such as touchesBegan: have been overridden. Here the 
> relevant code sniplet from that file:
> 
>     VTABLE_PTR func = 
> thiz->tib->vtable[XMLVM_VTABLE_IDX_org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent];
>     if (func == (VTABLE_PTR) 
> org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent) 
> {
>         // vtable index for this method still points to the 
> implementation of
>         // class UIResponder. Delegate event to the next responder
> 		[[self nextResponder] touchesBegan:touches withEvent:event];
> 
> If the if-condition is true, the method has not been overridden.
> 
> Hope this helps,
> Arno
> 
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network 
> management toolset available today.  Delivers lowest initial 
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Optional Methods in C-Backend

[Arno P. <ar...@pu...>]

this is a loaded question. What you are effectively trying to do is to 
introduce optional methods into the Java language. I know that there 
once was a JSR for doing exactly that, but it never got adopted (and I 
don't know the reason why it didn't get adopted).

I don't think such an annotation would help in this case. The C backend 
knows nothing about Objective-C. In fact, the parts that are in 
Objective-C are manually written (i.e., not generated) and injected into 
the C wrappers. Whoever writes the wrapper for UITableViewDelegate 
(probably me) has to do the 'magic' with respondsToSelector as Panayotis 
explained.

Note that quite a while ago (sometime last year) we had a longer 
discussion on how to represent iOS API in Java when it comes to optional 
methods. Fact is, that we are constricted by the Java syntax and 
semantics and such an XMLVM-specific annotation can't help here.

Arno


On 5/5/11 12:24 PM, Markus Heberling wrote:
> Hi.
>
> shouldn't this be done automagically by xmlvm?
>
> Like adding an @Optional annotation, that can be put on optional methods in java classes, and xmlvm will generate the correct respondsToSelector?
>
>
> Regards,
> Markus
>
> Am 05.05.2011 um 18:19 schrieb Arno Puder:
>
>>
>>
>> On 5/5/11 6:30 AM, Panayotis Katsaloulis wrote:
>>>
>>> On 05 Μαϊ 2011, at 11:35 π.μ., Markus Heberling wrote:
>>>
>>>> Hi,
>>>>
>>>> I'd like to use a UITableViewDelegate with the C Backend. Some methods
>>>> in that class are optional. XMLVM generates stubs for the, that throw
>>>> the XMLVM_NOT_IMPLEMENTED Error:
>>>>
>>>> JAVA_FLOAT
>>>> org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath(JAVA_OBJECT
>>>> me, JAVA_OBJECT n1, JAVA_OBJECT n2)
>>>> {
>>>> //XMLVM_BEGIN_WRAPPER[org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath]
>>>> XMLVM_NOT_IMPLEMENTED();
>>>> //XMLVM_END_WRAPPER
>>>> }
>>>>
>>>> I can override all of the methods, of course, but I rather would leave
>>>> them out. What would be the correct way to handle optional methods?
>>>>
>>>> Markus
>>>
>>> I can't help you with the C backend, but I'll describe a bit what I did
>>> in the same case with the ObjC backend, so that the C Gurus here could
>>> advise the correct answer.
>>>
>>> The problem is, there is no "default" value for these (and all similar)
>>> methods. Moreover, the iOS would behave different, when these methods
>>> are present, and do something else, when these methods are missing.
>>>
>>> What I did on the ObjC backend was to do something similar to what (I
>>> believe) Apple does.
>>> First of all, *all* ObjC delegate methods exist and all point to their
>>> Java counterpart.
>>> Then the method that answers to the ObjC runtime if this method exists
>>> (i.e. respondsToSelector) is overridden. If an actual Java-based
>>> implementation exists, then respondsToSelector responds that the actual
>>> ObjC delegate selector exists (although the ObjC selector *always*
>>> exist). If it doesn't then it replies that this method does not exist.
>>>
>>> WIth such a trick it is possible to properly inform the UITableView that
>>> an optional *Java* method exist, and have the desired/correct behavior.
>>
>> You can do the same with the C backend. The key is to implement
>> respondsToSelector in UITableViewDelegate in such a way that it figures
>> out if a Java method has been overridden or not. This can easily be done
>> with the help of the vtable: if a method is overridden in a derived
>> class, the vtable entry for that method will point to the implementation
>> in the derived class. If the method has not been overridden, the vtable
>> entry will still point to the implementation of the base class. The same
>> trick is used in org_xmlvm_iphone_UIResponder.m (for the C backend) to
>> check if methods such as touchesBegan: have been overridden. Here the
>> relevant code sniplet from that file:
>>
>>      VTABLE_PTR func =
>> thiz->tib->vtable[XMLVM_VTABLE_IDX_org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent];
>>      if (func == (VTABLE_PTR)
>> org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent)
>> {
>>          // vtable index for this method still points to the
>> implementation of
>>          // class UIResponder. Delegate event to the next responder
>> 		[[self nextResponder] touchesBegan:touches withEvent:event];
>>
>> If the if-condition is true, the method has not been overridden.
>>
>> Hope this helps,
>> Arno
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Optional Methods in C-Backend

[Markus H. <ma...@ti...>]

Hi,

I have manually implemented optional method handling for 2 Methods from UITableViewDelegate. 

http://xmlvm-reviews.appspot.com/121001/

If you think that it is ok that way I would implement the other methods, too.

Markus

Am 06.05.2011 um 02:02 schrieb Arno Puder:

> 
> this is a loaded question. What you are effectively trying to do is to 
> introduce optional methods into the Java language. I know that there 
> once was a JSR for doing exactly that, but it never got adopted (and I 
> don't know the reason why it didn't get adopted).
> 
> I don't think such an annotation would help in this case. The C backend 
> knows nothing about Objective-C. In fact, the parts that are in 
> Objective-C are manually written (i.e., not generated) and injected into 
> the C wrappers. Whoever writes the wrapper for UITableViewDelegate 
> (probably me) has to do the 'magic' with respondsToSelector as Panayotis 
> explained.
> 
> Note that quite a while ago (sometime last year) we had a longer 
> discussion on how to represent iOS API in Java when it comes to optional 
> methods. Fact is, that we are constricted by the Java syntax and 
> semantics and such an XMLVM-specific annotation can't help here.
> 
> Arno
> 
> 
> On 5/5/11 12:24 PM, Markus Heberling wrote:
>> Hi.
>> 
>> shouldn't this be done automagically by xmlvm?
>> 
>> Like adding an @Optional annotation, that can be put on optional methods in java classes, and xmlvm will generate the correct respondsToSelector?
>> 
>> 
>> Regards,
>> Markus
>> 
>> Am 05.05.2011 um 18:19 schrieb Arno Puder:
>> 
>>> 
>>> 
>>> On 5/5/11 6:30 AM, Panayotis Katsaloulis wrote:
>>>> 
>>>> On 05 Μαϊ 2011, at 11:35 π.μ., Markus Heberling wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I'd like to use a UITableViewDelegate with the C Backend. Some methods
>>>>> in that class are optional. XMLVM generates stubs for the, that throw
>>>>> the XMLVM_NOT_IMPLEMENTED Error:
>>>>> 
>>>>> JAVA_FLOAT
>>>>> org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath(JAVA_OBJECT
>>>>> me, JAVA_OBJECT n1, JAVA_OBJECT n2)
>>>>> {
>>>>> //XMLVM_BEGIN_WRAPPER[org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath]
>>>>> XMLVM_NOT_IMPLEMENTED();
>>>>> //XMLVM_END_WRAPPER
>>>>> }
>>>>> 
>>>>> I can override all of the methods, of course, but I rather would leave
>>>>> them out. What would be the correct way to handle optional methods?
>>>>> 
>>>>> Markus
>>>> 
>>>> I can't help you with the C backend, but I'll describe a bit what I did
>>>> in the same case with the ObjC backend, so that the C Gurus here could
>>>> advise the correct answer.
>>>> 
>>>> The problem is, there is no "default" value for these (and all similar)
>>>> methods. Moreover, the iOS would behave different, when these methods
>>>> are present, and do something else, when these methods are missing.
>>>> 
>>>> What I did on the ObjC backend was to do something similar to what (I
>>>> believe) Apple does.
>>>> First of all, *all* ObjC delegate methods exist and all point to their
>>>> Java counterpart.
>>>> Then the method that answers to the ObjC runtime if this method exists
>>>> (i.e. respondsToSelector) is overridden. If an actual Java-based
>>>> implementation exists, then respondsToSelector responds that the actual
>>>> ObjC delegate selector exists (although the ObjC selector *always*
>>>> exist). If it doesn't then it replies that this method does not exist.
>>>> 
>>>> WIth such a trick it is possible to properly inform the UITableView that
>>>> an optional *Java* method exist, and have the desired/correct behavior.
>>> 
>>> You can do the same with the C backend. The key is to implement
>>> respondsToSelector in UITableViewDelegate in such a way that it figures
>>> out if a Java method has been overridden or not. This can easily be done
>>> with the help of the vtable: if a method is overridden in a derived
>>> class, the vtable entry for that method will point to the implementation
>>> in the derived class. If the method has not been overridden, the vtable
>>> entry will still point to the implementation of the base class. The same
>>> trick is used in org_xmlvm_iphone_UIResponder.m (for the C backend) to
>>> check if methods such as touchesBegan: have been overridden. Here the
>>> relevant code sniplet from that file:
>>> 
>>>     VTABLE_PTR func =
>>> thiz->tib->vtable[XMLVM_VTABLE_IDX_org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent];
>>>     if (func == (VTABLE_PTR)
>>> org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent)
>>> {
>>>         // vtable index for this method still points to the
>>> implementation of
>>>         // class UIResponder. Delegate event to the next responder
>>> 		[[self nextResponder] touchesBegan:touches withEvent:event];
>>> 
>>> If the if-condition is true, the method has not been overridden.
>>> 
>>> Hope this helps,
>>> Arno
>>> 
>>> ------------------------------------------------------------------------------
>>> WhatsUp Gold - Download Free Network Management Software
>>> The most intuitive, comprehensive, and cost-effective network
>>> management toolset available today.  Delivers lowest initial
>>> acquisition cost and overall TCO of any competing solution.
>>> http://p.sf.net/sfu/whatsupgold-sd
>>> _______________________________________________
>>> xmlvm-users mailing list
>>> xml...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>> 
> 
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network 
> management toolset available today.  Delivers lowest initial 
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Optional Methods in C-Backend

[Arno P. <ar...@pu...>]

you got the gist of it. Two things:

1. In your boolean expression, you don't have to go through the TIB
    to retrieve the function pointer. You can inline the function
    directly as a constant.
2. It may be possible that the XMLVM_VTABLE_xxx symbol isn't defined.
    This can happen if the method is not overridden. XMLVM performs
    compile-time optimizations and will not even generate a vtable
    entry for that method. In this case, the result should always
    be FALSE.

Here a re-worked version:

if (aSelector == @selector(tableView:heightForRowAtIndexPath:)) {
#ifdef 
XMLVM_VTABLE_IDX_org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___ 
  VTABLE_PTR f = ((org_xmlvm_iphone_UITableViewDelegate*) 
delegate_)->tib-> 
vtable[XMLVM_VTABLE_IDX_org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath]; 
   return f != (VTABLE_PTR) 
org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath;
#else
   return 0;
#endif

If the mailer messes up the indentation and you can't read it, I'll send 
it as an attachment.

Arno



On 5/6/11 2:50 AM, Markus Heberling wrote:
> Hi,
>
> I have manually implemented optional method handling for 2 Methods from UITableViewDelegate.
>
> http://xmlvm-reviews.appspot.com/121001/
>
> If you think that it is ok that way I would implement the other methods, too.
>
> Markus
>
> Am 06.05.2011 um 02:02 schrieb Arno Puder:
>
>>
>> this is a loaded question. What you are effectively trying to do is to
>> introduce optional methods into the Java language. I know that there
>> once was a JSR for doing exactly that, but it never got adopted (and I
>> don't know the reason why it didn't get adopted).
>>
>> I don't think such an annotation would help in this case. The C backend
>> knows nothing about Objective-C. In fact, the parts that are in
>> Objective-C are manually written (i.e., not generated) and injected into
>> the C wrappers. Whoever writes the wrapper for UITableViewDelegate
>> (probably me) has to do the 'magic' with respondsToSelector as Panayotis
>> explained.
>>
>> Note that quite a while ago (sometime last year) we had a longer
>> discussion on how to represent iOS API in Java when it comes to optional
>> methods. Fact is, that we are constricted by the Java syntax and
>> semantics and such an XMLVM-specific annotation can't help here.
>>
>> Arno
>>
>>
>> On 5/5/11 12:24 PM, Markus Heberling wrote:
>>> Hi.
>>>
>>> shouldn't this be done automagically by xmlvm?
>>>
>>> Like adding an @Optional annotation, that can be put on optional methods in java classes, and xmlvm will generate the correct respondsToSelector?
>>>
>>>
>>> Regards,
>>> Markus
>>>
>>> Am 05.05.2011 um 18:19 schrieb Arno Puder:
>>>
>>>>
>>>>
>>>> On 5/5/11 6:30 AM, Panayotis Katsaloulis wrote:
>>>>>
>>>>> On 05 Μαϊ 2011, at 11:35 π.μ., Markus Heberling wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to use a UITableViewDelegate with the C Backend. Some methods
>>>>>> in that class are optional. XMLVM generates stubs for the, that throw
>>>>>> the XMLVM_NOT_IMPLEMENTED Error:
>>>>>>
>>>>>> JAVA_FLOAT
>>>>>> org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath(JAVA_OBJECT
>>>>>> me, JAVA_OBJECT n1, JAVA_OBJECT n2)
>>>>>> {
>>>>>> //XMLVM_BEGIN_WRAPPER[org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath]
>>>>>> XMLVM_NOT_IMPLEMENTED();
>>>>>> //XMLVM_END_WRAPPER
>>>>>> }
>>>>>>
>>>>>> I can override all of the methods, of course, but I rather would leave
>>>>>> them out. What would be the correct way to handle optional methods?
>>>>>>
>>>>>> Markus
>>>>>
>>>>> I can't help you with the C backend, but I'll describe a bit what I did
>>>>> in the same case with the ObjC backend, so that the C Gurus here could
>>>>> advise the correct answer.
>>>>>
>>>>> The problem is, there is no "default" value for these (and all similar)
>>>>> methods. Moreover, the iOS would behave different, when these methods
>>>>> are present, and do something else, when these methods are missing.
>>>>>
>>>>> What I did on the ObjC backend was to do something similar to what (I
>>>>> believe) Apple does.
>>>>> First of all, *all* ObjC delegate methods exist and all point to their
>>>>> Java counterpart.
>>>>> Then the method that answers to the ObjC runtime if this method exists
>>>>> (i.e. respondsToSelector) is overridden. If an actual Java-based
>>>>> implementation exists, then respondsToSelector responds that the actual
>>>>> ObjC delegate selector exists (although the ObjC selector *always*
>>>>> exist). If it doesn't then it replies that this method does not exist.
>>>>>
>>>>> WIth such a trick it is possible to properly inform the UITableView that
>>>>> an optional *Java* method exist, and have the desired/correct behavior.
>>>>
>>>> You can do the same with the C backend. The key is to implement
>>>> respondsToSelector in UITableViewDelegate in such a way that it figures
>>>> out if a Java method has been overridden or not. This can easily be done
>>>> with the help of the vtable: if a method is overridden in a derived
>>>> class, the vtable entry for that method will point to the implementation
>>>> in the derived class. If the method has not been overridden, the vtable
>>>> entry will still point to the implementation of the base class. The same
>>>> trick is used in org_xmlvm_iphone_UIResponder.m (for the C backend) to
>>>> check if methods such as touchesBegan: have been overridden. Here the
>>>> relevant code sniplet from that file:
>>>>
>>>>      VTABLE_PTR func =
>>>> thiz->tib->vtable[XMLVM_VTABLE_IDX_org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent];
>>>>      if (func == (VTABLE_PTR)
>>>> org_xmlvm_iphone_UIResponder_touchesBegan___java_util_Set_org_xmlvm_iphone_UIEvent)
>>>> {
>>>>          // vtable index for this method still points to the
>>>> implementation of
>>>>          // class UIResponder. Delegate event to the next responder
>>>> 		[[self nextResponder] touchesBegan:touches withEvent:event];
>>>>
>>>> If the if-condition is true, the method has not been overridden.
>>>>
>>>> Hope this helps,
>>>> Arno
>>>>
>>>> ------------------------------------------------------------------------------
>>>> WhatsUp Gold - Download Free Network Management Software
>>>> The most intuitive, comprehensive, and cost-effective network
>>>> management toolset available today.  Delivers lowest initial
>>>> acquisition cost and overall TCO of any competing solution.
>>>> http://p.sf.net/sfu/whatsupgold-sd
>>>> _______________________________________________
>>>> xmlvm-users mailing list
>>>> xml...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>>
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Optional Methods in C-Backend

[Panayotis K. <pan...@pa...>]

There is also one more thing.
I believe, if an optional method returns nothing, or the default value is already known, there is no reason to use the "respondsToSelector" method.

In the case of the known & documented default value, create a regular method which simply returns this value
(like for example "editingStyleForRowAtIndexPath")

In the case which does not return anything, just create an empty method.
(like for example "heightForRowAtIndexPath").

The problem is exactly with methods like "heightForRowAtIndexPath", where the default value is not known at all, and SHOULD return something.
*Then* it is required to do the respondsToSelector trick



On May 7, 2011, at 9:54 AM, Arno Puder wrote:

> 
> you got the gist of it. Two things:
> 
> 1. In your boolean expression, you don't have to go through the TIB
>    to retrieve the function pointer. You can inline the function
>    directly as a constant.
> 2. It may be possible that the XMLVM_VTABLE_xxx symbol isn't defined.
>    This can happen if the method is not overridden. XMLVM performs
>    compile-time optimizations and will not even generate a vtable
>    entry for that method. In this case, the result should always
>    be FALSE.
> 
> Here a re-worked version:
> 
> if (aSelector == @selector(tableView:heightForRowAtIndexPath:)) {
> #ifdef 
> XMLVM_VTABLE_IDX_org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___ 
>  VTABLE_PTR f = ((org_xmlvm_iphone_UITableViewDelegate*) 
> delegate_)->tib-> 
> vtable[XMLVM_VTABLE_IDX_org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath]; 
>   return f != (VTABLE_PTR) 
> org_xmlvm_iphone_UITableViewDelegate_heightForRowAtIndexPath___org_xmlvm_iphone_UITableView_org_xmlvm_iphone_NSIndexPath;
> #else
>   return 0;
> #endif
> 
> If the mailer messes up the indentation and you can't read it, I'll send 
> it as an attachment.
> 
> Arno
> 
> 
> 
> On 5/6/11 2:50 AM, Markus Heberling wrote:
>> Hi,
>> 
>> I have manually implemented optional method handling for 2 Methods from UITableViewDelegate.
>> 
>> http://xmlvm-reviews.appspot.com/121001/
>> 
>> If you think that it is ok that way I would implement the other methods, too.
>> 
>> Markus