Menu
▾
▴
Re: [xmlvm-users] Collections Framework Design
|
From: Arno P. <ar...@pu...> - 2010-03-27 09:01:34
|
Consider class UIView in Cocoa. It has a property 'subviews' that allows
you access to all children of a given UIView. This list of children is
returned as NSArray*. By using categories, we can make java_util_List a
category of NSArray. The huge advantage is that you can simply pass
NSArray* through to the Java side where it can be transparently accessed
as java.util.List. If it were anything else, you would have to first
convert the data structure.
Arno
On 3/26/10 7:40 PM, Paul Poley wrote:
> Resending to everyone on the distribution list instead of just Gergely:
>
>
> 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.
>
>
> However, I am happy to conform to this, as there seems to be a consensus
> that this is the way to go.
>
>
> I will be looking further into the details tomorrow, such as how you
> mentioned proxies, so please excuse any oversight for the time being. I
> would just like to keep up the conversation.
>
>
> 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.
>
> 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;
>
> }
>
>
>
> Above, both extending java_lang_Object and attempting to add a member
> variable will cause a compile error.
>
>
> To further expand upon my concerns, in my proposed HashMap
> implementation (in patch 32001), I used member variables, but this isn't
> possible with categories to my understanding. Technically the HashMap
> should be backed by an entrySet member variable (it isn't because it's
> backed by an NSMutableDictionary).
>
>
> 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.
>
>
> Gergely,
>
> I assume my patch (32001) is what inspired your e-mail. Although we're
> working in the same area, I don't think we're conflicting in a horrible
> way (correct me if you think I am wrong). E.g. see HashSet in both of
> our patches.
>
>
> Could you elaborate on your comment "Need to support subclassing for
> non-final classes"? It sounds like you're expressing the same issue I am.
>
>
> I plan on taking a better look at this tomorrow to make sure we're on
> the same page.
>
>
> Per Wolfgang's comments, I will be refactoring HashMap & HashSet to use
> categories. Please feel free to comment on my updated patch when I
> complete it.
>
>
> On Fri, Mar 26, 2010 at 12:58 PM, Gergely Kis <ger...@ma...
> <mailto:ger...@ma...>> wrote:
>
> Hi,
>
> There are already multiple patches in the review queue for the
> Collections Framework. Following my previous suggestion, I am now
> trying to open a discussion regarding the design of the collections
> framework. In our patch (http://xmlvm-reviews.appspot.com/18002) you
> can already see a partial implementation of this suggestion.
>
> Requirements:
> 1. Need to support seamless integration between regular ObjC types
> (NSArray ... etc.) and Java classes -> use categories
> 2. Need to support subclassing for non-final classes. This is a
> problem with using class clusters as the basis.
>
> The proposal:
> 1. Create the interfaces as protocols (java_util_List, java_util_Map
> ... etc.)
> 2. Implement the interfaces as categories of the non-mutable ObjC
> collection classes. (NSArray, NSSet, NSDictionary)
> - The mutator methods are implemented to throw
> UnsupportedOperationException. In essence you receive the same
> behavior as if you used Collections.unmodifiable*() methods
> 3. Only implement the mutator methods in the NSMutable* collection
> classes.
>
> At this point any ObjC collection can be used as a regular Java
> collection.
> Now we need to implement the actual concrete classes.
>
> However class clusters cannot be subclassed easily.
> The solution is to implement the concrete classes using NSProxy.
> (See how java_util_Vector is implemented in our patch).
> However, this implementation adds an unnecessary indirection and
> performance overhead. So the idea is to detect in the proxy class
> init function whether a subclass is instantiated.
> If it is not a subclass, then simply return the appropriate
> NSMutable* instance. Otherwise return the proxy.
>
> What do you think? If you agree with this approach we can clean up
> our implementation, and submit it separately.
>
> Best Regards,
> Gergely
>
> --
> Kis Gergely
> MattaKis Consulting
> Email: ger...@ma... <mailto:ger...@ma...>
> Web: http://www.mattakis.com
> Phone: +36 70 408 1723
> Fax: +36 27 998 622
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> <mailto:xml...@li...>
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
|
