xmlvm-users

[xmlvm-users] UIViewAnimationDelegate is broken

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

Hello all!

After revision 2080 (committed by ppoley), the UIViewAnimationDelegate is broken in the ObjC version.
Although in Java it is defined as an interface, in ObjC is defined as an abstract class.

This would bring once more the question, interfaces or abstract classes, but at any case, for the time being, the ObjC part in terms of some UIView parts is broken. 

Re: [xmlvm-users] UIViewAnimationDelegate is broken

[Paul P. <bay...@gm...>]

Yes, that's correct.  We had a discussion regarding protocols at the time,
and it was decided to use interfaces, which I believe is the right
decision.  There were a few topics, but the main one was the difficultly of
implementation.  In the end, using Java interfaces with Obj-C protocols
involved using wrapper instances to invoke the correct Java methods.

Architecturally, I do not believe we should change back to abstract
classes.  Additionally, I have found that the C version of XMLVM has
exceeded the Obj-C version.  While it is unfortunate that forward progress
has broken that part of the Obj-C version of XMLVM, I am not sure it is
worth it to spend time on the Obj-C version, which I view as legacy.  To me
that means that some prior projects may use the Obj-C version, but
continued support isn't necessary.  Released projects should be dependent
on fixed source code, so the evolution of XMLVM shouldn't affect them.  I
certainly wouldn't object if someone wanted to provide an update though,
and I would be happy to give some pointers.

I understand that you are still invested in the Obj-C version, so I'm sure
we'll have a difference of opinion & I'd like to hear your point of view as
well.

Thanks,
Paul



On Thu, Feb 23, 2012 at 9:14 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> Hello all!
>
> After revision 2080 (committed by ppoley), the UIViewAnimationDelegate is
> broken in the ObjC version.
> Although in Java it is defined as an interface, in ObjC is defined as an
> abstract class.
>
> This would bring once more the question, interfaces or abstract classes,
> but at any case, for the time being, the ObjC part in terms of some UIView
> parts is broken.
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] UIViewAnimationDelegate is broken

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

On 23 Φεβ 2012, at 6:23 μ.μ., Paul Poley wrote:

> Yes, that's correct.  We had a discussion regarding protocols at the time, and it was decided to use interfaces, which I believe is the right decision.  There were a few topics, but the main one was the difficultly of implementation.  In the end, using Java interfaces with Obj-C protocols involved using wrapper instances to invoke the correct Java methods.
> 
> Architecturally, I do not believe we should change back to abstract classes.  Additionally, I have found that the C version of XMLVM has exceeded the Obj-C version.  While it is unfortunate that forward progress has broken that part of the Obj-C version of XMLVM, I am not sure it is worth it to spend time on the Obj-C version, which I view as legacy.  To me that means that some prior projects may use the Obj-C version, but continued support isn't necessary.  Released projects should be dependent on fixed source code, so the evolution of XMLVM shouldn't affect them.  I certainly wouldn't object if someone wanted to provide an update though, and I would be happy to give some pointers.
> 
> I understand that you are still invested in the Obj-C version, so I'm sure we'll have a difference of opinion & I'd like to hear your point of view as well.
> 
> Thanks,
> Paul


First of all, I don't mind whether it's better to use interfaces or abstract classes.
Everything is fine with me.

I agree that C is the future, but unfortunately it's not the present (yet). It is far form complete and, although ObjC is far from being optimized, I believe it's not time yet to drop support for it.
This time will come, only when the C backend is at least as feature-full as the ObjC backend.

I don't care if the backend will be C, or ObjC or any other exotic implementation. I do care though, if a project is able to run under revision 2079 (even with legacy ObjC), and doesn't run with 2080, with either backends.

Thanks, too 
:)

Re: [xmlvm-users] UIViewAnimationDelegate is broken

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

On 02/23/2012 11:21 AM, Panayotis Katsaloulis wrote:
>
> On 23 Φεβ 2012, at 6:23 μ.μ., Paul Poley wrote:
>
>> Yes, that's correct.  We had a discussion regarding protocols at the time, and it was decided to use interfaces, which I believe is the right decision.  There were a few topics, but the main one was the difficultly of implementation.  In the end, using Java interfaces with Obj-C protocols involved using wrapper instances to invoke the correct Java methods.
>>
>> Architecturally, I do not believe we should change back to abstract classes.  Additionally, I have found that the C version of XMLVM has exceeded the Obj-C version.  While it is unfortunate that forward progress has broken that part of the Obj-C version of XMLVM, I am not sure it is worth it to spend time on the Obj-C version, which I view as legacy.  To me that means that some prior projects may use the Obj-C version, but continued support isn't necessary.  Released projects should be dependent on fixed source code, so the evolution of XMLVM shouldn't affect them.  I certainly wouldn't object if someone wanted to provide an update though, and I would be happy to give some pointers.
>>
>> I understand that you are still invested in the Obj-C version, so I'm sure we'll have a difference of opinion&  I'd like to hear your point of view as well.
>>
>> Thanks,
>> Paul
>
>
> First of all, I don't mind whether it's better to use interfaces or abstract classes.
> Everything is fine with me.
>
> I agree that C is the future, but unfortunately it's not the present (yet). It is far form complete and, although ObjC is far from being optimized, I believe it's not time yet to drop support for it.
> This time will come, only when the C backend is at least as feature-full as the ObjC backend.
>
> I don't care if the backend will be C, or ObjC or any other exotic implementation. I do care though, if a project is able to run under revision 2079 (even with legacy ObjC), and doesn't run with 2080, with either backends.
>
> Thanks, too
> :)

Ideally it would be best to maintain the Objective-C backend while 
pushing the new C backend. I agree that it is not optimal that there are 
problems with the Objective-C backend before we can finally move over to 
the C backend. However, it is also a sad reality that we have extremely 
limited resources and simply don't have any spare cycles to invest into 
something that will soon be retired. Since you don't use the C backend 
you might want to stay with revision 2080.

Arno

Re: [xmlvm-users] UIViewAnimationDelegate is broken

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

On 23 Φεβ 2012, at 9:37 μ.μ., Arno Puder wrote:

> 
> Ideally it would be best to maintain the Objective-C backend while 
> pushing the new C backend. I agree that it is not optimal that there are 
> problems with the Objective-C backend before we can finally move over to 
> the C backend. However, it is also a sad reality that we have extremely 
> limited resources and simply don't have any spare cycles to invest into 
> something that will soon be retired. Since you don't use the C backend 
> you might want to stay with revision 2080.
> 
> Arno

Unfortunately, I can't.
For example, UIPopoverController was committed in revision 2103 by me, and I need it. 

Of course I know how to fix this in ObjC.
My point of view thought is, not to break something that works, to replace it with something that doesn't fully work yet.

Like in Debian: if something breaks we should keep both parts.

Re: [xmlvm-users] UIViewAnimationDelegate is broken

[Paul P. <bay...@gm...>]

Agreed - limited resources & retirement considerations.

If you are interested in remedying the Obj-C issue, I don't mind giving
some pointers.  Take note that one method name in UIViewAnimationDelegate
had changed from "animationWillStart" to "animationDidStart", and both
methods gained "Object context".  The name changed to match the actual
Obj-C delegate methods, not to be confused with the method that sets the
selector ("setAnimationWillStartSelector:").

An FYI - UIViewAnimationDelegate hasn't yet been updated to use more
generated code via @XMLVMDelegateMethod like NSNetServiceBrowserDelegate,
but that shouldn't affect the Obj-C version anyways.

Thanks,
Paul


On Thu, Feb 23, 2012 at 1:37 PM, Arno Puder <ar...@pu...> wrote:

>
> Ideally it would be best to maintain the Objective-C backend while
> pushing the new C backend. I agree that it is not optimal that there are
> problems with the Objective-C backend before we can finally move over to
> the C backend. However, it is also a sad reality that we have extremely
> limited resources and simply don't have any spare cycles to invest into
> something that will soon be retired. Since you don't use the C backend
> you might want to stay with revision 2080.
>
> Arno
>

Re: [xmlvm-users] UIViewAnimationDelegate is broken

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

On 23 Φεβ 2012, at 10:49 μ.μ., Paul Poley wrote:

> Take note that one method name in UIViewAnimationDelegate had changed from "animationWillStart" to "animationDidStart", and both methods gained "Object context".  The name changed to match the actual Obj-C delegate methods, not to be confused with the method that sets the selector ("setAnimationWillStartSelector:").


I am not sure about it.
If you read the docs, it clearly states that one must specifically set the actual selector. The name could be anything, like
animationDidStart___java_lang_String_java_lang_Object::
or
animationDidStop___java_lang_String_boolean_java_lang_Object:::
which is something I already did (with success) in svn -r 2155

Of course, it's only a name (of lesser importance), but from my understanding "animationWillStart" is more appropriate, because this is a name that appears in the API, not in the comments.

Re: [xmlvm-users] UIViewAnimationDelegate is broken

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

the Java compiler sometimes will introduce so-called synthetic variables 
to keep a reference to the surrounding context. This happens for some 
type of inner classes as well as anonymous classes. These synthetic 
references usually lead to cycles in the dependency graph. The 
Objective-C backend uses reference counting as a means for memory 
management and a cycle results in a memory leak. That is why we have 
decided in the old days to make synthetic references weak (to break the 
cycle). So, to your questions: if you made those references strong, you 
would end up with a memory leak. Since a garbage collector can deal with 
those situation, this is not a problem with the C backend.

Arno


On 2/24/12 5:58 AM, Panayotis Katsaloulis wrote:
>
> On 23 Φεβ 2012, at 10:49 μ.μ., Paul Poley wrote:
>
>> Take note that one method name in UIViewAnimationDelegate had changed from "animationWillStart" to "animationDidStart", and both methods gained "Object context".  The name changed to match the actual Obj-C delegate methods, not to be confused with the method that sets the selector ("setAnimationWillStartSelector:").
>
>
> I am not sure about it.
> If you read the docs, it clearly states that one must specifically set the actual selector. The name could be anything, like
> animationDidStart___java_lang_String_java_lang_Object::
> or
> animationDidStop___java_lang_String_boolean_java_lang_Object:::
> which is something I already did (with success) in svn -r 2155
>
> Of course, it's only a name (of lesser importance), but from my understanding "animationWillStart" is more appropriate, because this is a name that appears in the API, not in the comments.
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] UIViewAnimationDelegate is broken

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

On 24 Φεβ 2012, at 6:51 μ.μ., Arno Puder wrote:

> if you made those references strong, you 
> would end up with a memory leak. Since a garbage collector can deal with 
> those situation, this is not a problem with the C backend.


Thank you for the clarification.
This explains the observed "weak" behavior in the ObjC backend and makes me confident that the issue is (will be) resolved in the C backend.