xmlvm-users

[xmlvm-users] NsTimerDelegate

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

Hello all!

I'd like to ask you about the introduction of the NSTimerDelegate object. 
I believe this idea was not so good. This is something that does not belong to the iOS sdk, and I strongly believer we should be as strict as possible with this, and violate it *only* there is NO other way of doing it. 
We don't have specific documentation for xmlvm, so please at least b compatible with the documentation being written by others ;) ( namely Apple)


--
Panayotis

Re: [xmlvm-users] NsTimerDelegate

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

just to explain that change: NSTimer in Objective-C allows to trigger 
arbitrary methods. This is easy in Objective-C since this language is 
dynamically typed. So far we mimicked this in Java by using reflection. 
However, Java is a strongly typed language and doing it this way is not 
in the spirit of the language. That is why we introduced NSTimerDelegate.

Note that at some point we need to make design decisions where we cannot 
easily map Objective-C to Java (another example are optional methods in 
Objective-C protocols. Here we also deviate from the "official Apple 
documentation"). Its a design decision but I believe its a good one.

Arno


On 9/11/10 2:35 AM, Panayotis Katsaloulis wrote:
> Hello all!
>
> I'd like to ask you about the introduction of the NSTimerDelegate object.
> I believe this idea was not so good. This is something that does not belong to the iOS sdk, and I strongly believer we should be as strict as possible with this, and violate it *only* there is NO other way of doing it.
> We don't have specific documentation for xmlvm, so please at least b compatible with the documentation being written by others ;) ( namely Apple)
>
>
> --
> Panayotis
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] NsTimerDelegate

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

Well, you are the boss, but I I don't see the problem on using reflection. 
And in some situations, we can't avoid it at all (like the important selector "performSelectorOnMainThread")

Now, about the other problem of optional selectors, I believe I gave a nice solution with org.xmlvm.iphone.internal.OptionalSelectorException. 
Of course, the emulator should follow some guidelines, but in any case I believe it is an elegant solution

In both cases, the API was completely compatible with Java and ObjC at the same time :)




--
Panayotis

11 Σεπ 2010, 12:42 μ.μ., ο/η Arno Puder <ar...@pu...> έγραψε:

> 
> just to explain that change: NSTimer in Objective-C allows to trigger 
> arbitrary methods. This is easy in Objective-C since this language is 
> dynamically typed. So far we mimicked this in Java by using reflection. 
> However, Java is a strongly typed language and doing it this way is not 
> in the spirit of the language. That is why we introduced NSTimerDelegate.
> 
> Note that at some point we need to make design decisions where we cannot 
> easily map Objective-C to Java (another example are optional methods in 
> Objective-C protocols. Here we also deviate from the "official Apple 
> documentation"). Its a design decision but I believe its a good one.
> 
> Arno
> 

Re: [xmlvm-users] NsTimerDelegate

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

well, I was referring to the fact that sometimes we map Objective-C 
protocols to Java class and sometimes to Java interfaces. Of course we 
do this consistently, but its a design decision. Likewise its a design 
decision to map Objective-C @selector to a strongly-typed interface in 
those cases where it is possible.

Arno


On 9/11/10 3:20 AM, Panayotis Katsaloulis wrote:
> Well, you are the boss, but I I don't see the problem on using reflection.
> And in some situations, we can't avoid it at all (like the important selector "performSelectorOnMainThread")
>
> Now, about the other problem of optional selectors, I believe I gave a nice solution with org.xmlvm.iphone.internal.OptionalSelectorException.
> Of course, the emulator should follow some guidelines, but in any case I believe it is an elegant solution
>
> In both cases, the API was completely compatible with Java and ObjC at the same time :)
>
>
>
>
> --
> Panayotis
>
> 11 Σεπ 2010, 12:42 μ.μ., ο/η Arno Puder<ar...@pu...>  έγραψε:
>
>>
>> just to explain that change: NSTimer in Objective-C allows to trigger
>> arbitrary methods. This is easy in Objective-C since this language is
>> dynamically typed. So far we mimicked this in Java by using reflection.
>> However, Java is a strongly typed language and doing it this way is not
>> in the spirit of the language. That is why we introduced NSTimerDelegate.
>>
>> Note that at some point we need to make design decisions where we cannot
>> easily map Objective-C to Java (another example are optional methods in
>> Objective-C protocols. Here we also deviate from the "official Apple
>> documentation"). Its a design decision but I believe its a good one.
>>
>> Arno
>>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] NsTimerDelegate

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

11 Σεπ 2010, 1:59 μ.μ., ο/η Arno Puder <ar...@pu...> έγραψε:

> 
> well, I was referring to the fact that sometimes we map Objective-C 
> protocols to Java class and sometimes to Java interfaces. Of course we 
> do this consistently, but its a design decision. Likewise its a design 
> decision to map Objective-C @selector to a strongly-typed interface in 
> those cases where it is possible.
> 
> Arno

Well, probably I am missing something, but I think that this is not always the case. There are some locations, like the one I mentioned before, that don't follow the strongly typed nature of Java. 
In any case, if you really believe that a strongly typed declaration is preferred, I'd at least suggest to create a new package for all these situations, something like org.xmlvm.iphone.support (or anything similar) and keep all non-standard objects there, while having heavy documentation on these classes (although still I believe is not the best solution)

Re: [xmlvm-users] NsTimerDelegate

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

I'm sure there are plenty of "dark corners" in XMLVM where we are (not 
yet) consistent.  :-)  But I'm sure that will be cleaned up eventually.

A support package for non-standard classes/interfaces is a good idea!

Arno


On 9/11/10 4:08 AM, Panayotis Katsaloulis wrote:
>
> 11 Σεπ 2010, 1:59 μ.μ., ο/η Arno Puder<ar...@pu...>  έγραψε:
>
>>
>> well, I was referring to the fact that sometimes we map Objective-C
>> protocols to Java class and sometimes to Java interfaces. Of course we
>> do this consistently, but its a design decision. Likewise its a design
>> decision to map Objective-C @selector to a strongly-typed interface in
>> those cases where it is possible.
>>
>> Arno
>
> Well, probably I am missing something, but I think that this is not always the case. There are some locations, like the one I mentioned before, that don't follow the strongly typed nature of Java.
> In any case, if you really believe that a strongly typed declaration is preferred, I'd at least suggest to create a new package for all these situations, something like org.xmlvm.iphone.support (or anything similar) and keep all non-standard objects there, while having heavy documentation on these classes (although still I believe is not the best solution)
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users