Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

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

An associative reference looks to be just what I need.  I'm assuming it
works with at least the latest version of iOS 3 & not just 4.0 & beyond.

I suppose the best solution is to lazily create the reference only when
first needed, since most objects won't need it.  That will also not create
any overhead to existing functionality.

Thanks Arno!  I'll try that.

While still somewhat on topic, I need to throw an
IllegalMonitorStateException if the current thread is not the owner of the
object's monitor.  In Java, this is native code, and I am uncertain how to
check this in Objective-C.  Googling didn't help me much either.  Does
anyone know how to check in Objective-C?

Thanks!
Paul

On Mon, Jul 12, 2010 at 3:25 AM, Arno Puder <ar...@pu...> wrote:

>
> Apple recently added something called Associative References that might
> help with what you need:
>
> http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html
>
> Arno
>
>
> On 7/12/10 7:22 AM, Paul Poley wrote:
> > Regarding categories & cross-compiling the original JRE classes, I am
> > trying to implement:
> >
> > wait()
> > wait(long)
> > notify()
> > notifyAll()
> >
> > 1) If cross-compiling the original JRE, we will of course still need to
> > implement the native methods, including java.lang.Object's wait/notify
> > 2) Unfortunately my implementation of wait/notify requires me to keep
> > some state in java_lang_Object & I cannot do so since it is a category.
> >   Is there a way around this in XMLVM's current state?
> >
> > I believe I have everything written out, although it's a theoretical
> > solution right now.  However, because I need member variables, I cannot
> > try it out without changing java_lang_Object to inherit from NSObject
> > rather than be a category.  That causes other issues though.  For
> > example, many XMLVM objects represented as categories of objective-c
> > objects automatically share the benefits of java_lang_Object without
> > explicitly saying so, as needed.  Using inheritance for java_lang_Object
> > instead of categories removes this currently necessary benefit.
> >
> > Does anyone have any suggestions?  If we can get that working,
> > implementing Thread interruptions shouldn't be very difficult building
> > upon this.
> >
> > Thanks!
> > Paul Poley
> >
> >
> > On Sun, Jul 11, 2010 at 6:47 AM, Arno Puder <ar...@pu...
> > <mailto:ar...@pu...>> wrote:
> >
> >
> >     there are always trait-offs when you map from one platform to
> another.
> >     The efficiency of using categories comes with the downside you've
> >     described.
> >
> >     We are currently working on cross-compiling the original JRE classes
> >     from OpenJDK. For one, it would give us instant 100% compatibility
> and
> >     the issues you have described would also be resolved. Note that this
> is
> >     ongoing work and will take some time to complete.
> >
> >     Arno
> >
> >
> >     On 7/7/10 7:31 PM, bar...@ao... <mailto:bar...@ao...> wrote:
> >      >
> >      > I think that having java_util_ArrayList.m be a category on
> >      > NSMutableArray is a clever use of categories, but wouldn't
> >     encapsulation
> >      > generally be a more flexible option? One potential issue I see
> >     with the
> >      > category approach is that since java_util_ArrayList.m and
> >      > java_util_LinkedList.m are both categories on NSMutableArray, what
> >      > happens if the client java code relies on checking the kind of
> >     the list
> >      > using reflection? Won't java_util_ArrayList and
> java_util_LinkedList
> >      > then be indistinguishable from each other at runtime?
> >      >
> >      > The same goes for the other classes where categories are used:
> >     String,
> >      > StringBuffer, HashMap/Set, URI/URL, etc.
> >      >
> >      >
> >      >
> >      >
> >
> ------------------------------------------------------------------------------
> >      > This SF.net email is sponsored by Sprint
> >      > What will you do first with EVO, the first 4G phone?
> >      > Visit sprint.com/first <http://sprint.com/first> --
> >     http://p.sf.net/sfu/sprint-com-first
> >      >
> >      >
> >      >
> >      > _______________________________________________
> >      > xmlvm-users mailing list
> >      > xml...@li...
> >     <mailto:xml...@li...>
> >      > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >
> >
> ------------------------------------------------------------------------------
> >     This SF.net email is sponsored by Sprint
> >     What will you do first with EVO, the first 4G phone?
> >     Visit sprint.com/first <http://sprint.com/first> --
> >     http://p.sf.net/sfu/sprint-com-first
> >     _______________________________________________
> >     xmlvm-users mailing list
> >     xml...@li...
> >     <mailto:xml...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >
> >
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>