Re: [xmlvm-dev] My Java iOS API feedback

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

For protocols, I'd recommend we keep them as interfaces.  We could
optionally add "adapters", which are empty implementations of the
interface.  That way you could extend the adapter & only add the methods you
want, or implement the interface & provide all of them.

For char* not being a String, you've got a good point about other languages
Panayotis (that it should be byte[] instead - as read in the other email
thread).  Perhaps when it is always appropriate to be a String, we can add
details to the "advisor", so that it will be a String instead of byte[] in
certain instances?  That may not be worth it though.

Paul

On Mon, Oct 10, 2011 at 6:39 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On 10 Οκτ 2011, at 7:25 π.μ., Arno Puder wrote:
>
> >
> > first of all: very nice work! I like the JavaDoc that makes it easy to
> > correlate the Objective-C API with the Java counterpart.
> >
> > A few things:
> >
> > (1) I would like to move everything to the namespace org.xmlvm.ios.*. I
> > wanted to do that for a long time but with the new API existing apps
> > need to be changed anyways.
>
> I wanted to do that too, but I didn't want to touch this subject :)
>
>
> >
> > (2) All classes should have the @XMLVMSkeletonOnly annotation. Perhaps
> > add a command line argument that triggers the generation of this
> annotation.
>
> No problem
>
>
> > (3) I wonder if we should address the question of optional methods in
> > Objective-C protocols again. A long time ago we had a longer discussion
> > about this topic. Right now you map a protocol to a Java interface,
> > making all its methods mandatory.
>
> I am all ears.
> Do you think it would be better to produce XML files which could be parsed
> and create the actual API?
> Thus you can post-process whatever you want.
> The procedure though will be much more complicated than what it is now.
>
>
> > (4) The parser tool should use more "meta knowledge" to generate better
> > Java API. This should be added to advisor.xml. A couple of examples:
> >
> >   - UIView.getSubviews() should return List<UIView>, not just List
>
> There is already an API for that in advisor.xml
> In the reports there is also a list of methods that reflect this problem.
> Well, someone has to write it.
>
> My idea is to have an internal "advisor.xml" which will deal with all basic
> non-apple related stuff, and have an external XML at runtime which will live
> in XMLVM repository and deal with all specific issues.
> Of course, this means that all these details should be handled after the
> tool has been committed to the XMLVM repository.
>
>
>
> >   - As Aaron pointed out, const char* should be mapped to
> >     java.lang.String where appropriate.
>
> I disagree here, and I explained the reasons in the other email.
>
>
> >   - UIImage.writeToSavedPhotosAlbum(): the completionTarget and
> >     completionSelector should be combined to a Runnable.
>
> or use NSSelector instead?
> This is a topic that I didn't want to touch yet, until we have a clear
> agreement.
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>