Re: [Pyobjc-dev] Doc, it hurts when I say +isKindOfClass...

[Bill B. <bb...@co...>]

Actually, all of those classes should be-- for all intents and 
purposes-- totally hidden from the pyobjc module from the ObjC side.  
They are all internal classes that are designed to support things like 
distributed objects [distant object, protocol checker (sort of), 
nsproxy], effeciency hacks [nsmutablestring proxy], or debuggin 
[nszombie].

In any case, they mostly stand in-- or act as proxies-- to other 
instances.  For example, an NSProxy is used to represent an object that 
actually resides in a different runtime.  The NSProxy speaks across an 
NSConnection instance such that any method invocation against NSProxy is 
passed across the wire and executed in the foreign runtime.  Very 
cool.   At runtime, it also menas that an NSProxy instance may very well 
exist, but is nearly indistinguishable from the object it is proxying.

NSProxy is a root class;  hence, doesn't inherit from NSObject and 
doesn't implement any of the standard methods.

b.bum


On Friday, April 6, 2001, at 01:09 AM, Steven D. Majewski wrote:

>
>
> In the following code, the classes in skiplist will all
> generate objective-c runtime exceptions if they are touched:
>
> ----
> from pyobjc import runtime,lookup_class
>
> _Pool = runtime.NSAutoreleasePool()
>
> skiplist = [ 'NSConcreteProtocolChecker', 'NSDistantObject',
>         'NSInvocationBuilder', 'NSMutableStringProxy', 
> 'NSProtocolChecker'
> ,
>         'NSProxy' , '_NSZombie' ]
>
> for x in runtime.__objc_classes__:
>         if x not in skiplist:
>                 print x
>                 print lookup_class(x)
> ----
>
>
> All of the exceptions happens in ObjCObject_new().
>
>
> #   NSConcreteProtocolChecker
> #   NSDistantObject
> #   NSMutableStringProxy
> #   NSProtocolChecker
> #   NSProxy
> # Apr 05 23:54:51 python[2259] *** Uncaught exception:
> <NSInvalidArgumentException> *** -[NSProxy forwardInvocation:] called!
> #
> # caused by: [obj isKindOfClass: [NSAutoreleasePool class]]
> #
> #
> #   NSInvocationBuilder
> # Apr 05 23:54:41 python[2256] *** Uncaught exception:
> <NSInvalidArgumentException> target does not implement method
> #
> # caused by: [obj respondsToSelector:@selector (count)]
> #
> #
> #   _NSZombie           Bus error
>  (seems to be somewhere close to the one above)
>
> I'm quite willing to believe that whatever "_NSZombie" is, it
> probably shouln't be touched. Most likely all of the classes
> with a leading underscore in their names are not meant to be
> exposed and should be removed from the Python-Objc runtime.
>
> NSInvocationBuilder is undocumented (not even in the header
> files) and I'm even unable to see it in the Class Introspector.
>
> All of the first bunch, except for NSProxy are all subclasses of 
> NSProxy.
> NSProxy is another root class that is independent of NSObject.
> Looking at NSProxy with the Class Introspector, I can see that indeed,
> there is no class method for isKindOfClass: as there is in NSObject.
> ( NSObject has both a Class and an Instance isKindOfClass: )
>
>
> I was looking at this problem too see if it was related to some of
> the delegation bugs I've run into, but I'm now pretty convinced they
> are probably unrelated. I'm not sure if there is any likey case in
> which those classes would need to be called from Python -- perhaps
> they should all be removed from the runtime.
>
> For now, I'm going to leave them alone with just this warning:
>  don't try to access any of those classes from python.
>
> Does anyone know:
> Is there a reason that +[NSProxy isKindOfClass:] is not implemented
> or is it just an oversight (bug) ?
>
> -- Steve Majewski
>
>
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> http://lists.sourceforge.net/lists/listinfo/pyobjc-dev