Re: [xmlvm-users] Collections Framework Design

[Gergely K. <ger...@ma...>]

Hi Paul,

2010/3/27 Paul Poley <bay...@gm...>

> Resending to everyone on the distribution list instead of just Gergely:
>
Could someone change the reply-to in the list config to point to the mailing
list?


>
> I am not sure I fully understand the need to use categories, since the only
> code that should ever access the Java API in Objective-C is in fact the same
> API.  To put it another way, once the Java API is fully implemented in
> Obj-C, there would not ever be a case that I would explicitly reference a
> Java class in Obj-C.
>
I am not sure that I understand what you mean. Using categories enables us
to extend existing ObjC collection classes with the Java interface. This
means, that we don't have to reimplement List and Map functionality, we only
have to create a wrapper for the native NS* implementations. Categories are
the easiest way to do that in ObjC.



>
> That said, I am not sure how to have both a category and a subclass.  This
> brings up two issues (proxy solves these?):
>
> 1) HashMap should be a subclass of java.lang.Object, but I do not know how
> to do this using categories.
>
Well, in the ObjC compat lib we try to map as many Java types directly to
ObjC types, as possible. If you look at the java_lang_Object implementation:
it is just a typedef of NSObject, and NSObject is extended with the
necessary methods using the cat_java_lang_Object category.

Since ObjC is a dynamically typed OO environment, where the fact whether a
message (selector) is understood by an object is evaluated at runtime, any
NSObject derivative will behave like a java_lang_Object. The only part which
needs special treatment is the reflection and instanceof handling, so it
will correctly determine the type of such classes.



> 2) If I need more specific member variables, I cannot add them.
>
>
> Here's an example that will NOT work:
>
>
> typedef NSMutableDictionary java_util_HashMap;
>
>
> @interface NSMutableDictionary (cat_java_util_HashMap) : java_lang_Object {
>
> NSObject* someObject;
>
> }
>
>
> Yes, this is an issue with categories. If you look at the patch I
referenced, you will see how we solved this problem with regards to the
synchronized implementation, where we need to store a NSCondition for each
java_lang_Object. A similar method has been proposed by Panayotis.

However, in case of implementing java.util.HashMap, you don't need to use
member variables. In fact using a set of Entries in HashMap to store
elements is an implementation detail. You can either:
1. generate Entries for entrySet() on demand.
2. store the Entries in the underlying NSDictionary.

Probably solution 2 is the best, and makes it easy to support the semantics
of entrySet.

>
> As XMLVM is a work in progress, I have found that not all of the
> implemented API in Obj-C follows the Java contracts exactly, so I don't mind
> ignoring this minor blip in HashMap.  As a side note, the primary issue I'm
> referring to is classes with synchronization lacking said implementation.  I
> am trying to follow the Java API as much as possible.
>
Yes. Currently we implement the Java API on a "on demand" basis.
Unfortunately we also don't have a test suite yet, so there are probably
many nuances that don't follow the standard Java API behavior. I was
thinking about making sure that we can use JUnit, and then start using it
for creating tests. Internally we created some basic tests for our
implementations, but it does not use a framework currently.

I saw your patch in the review queue, but I had the outlined approach
implemented previously, as you can see from the patch. I wanted to bring
this issue up on the mailing list earlier, so it is purely a coincidence
with your patch. :)

Best Regards,
Gergely

-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622