gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] corebase/pyobjc


From: Matt Rice
Subject: Re: [patch] corebase/pyobjc
Date: Mon, 29 Aug 2011 19:56:43 -0700

On Mon, Aug 29, 2011 at 7:13 PM, Stefan Bidi <address@hidden> wrote:
> I still don't quite understand what is going on here.  CFStringInitialize()
> doesn't do anything accept call objc_getClass("NSCFString") (it's actually
> done by CFRuntimeBridgeClass).  According to the Apple docs this is safe
> because objc_getClass will call the class handler (not 100% what that really
> mean, but I thought it implied the class would get loaded if it belonged to
> the same framework) and try finding the class again afterward.
>
> Also, according to that doc, it isn't guaranteed that NSCFString is loaded
> before NSCFType, but how is this a problem?  CFString (and NSCFString)
> shouldn't be getting called during initialization anyway.
>
> I'm just trying to understand what your problem is and what is causing it.

I'm not too sure either, but If i had to venture a guess, i'd assume
the problem is that NSCFString's super-class is implemented in a
different framework, gnustep-base.

thus if corebase gets loaded first, NSCFType's super-class  NSObject's
+load is called, but doesn't initialize any of it's subclasses... then
it looks for NSCFString which isn't there yet

and if gnustep-base gets loaded first it goes through and initializes
all of its classes/subclasses, in that case NSCFString's super-class
exists at NSCFType call time and so it works.

or it could be that because *no* message is sent to the class from
+load to NSCFString it never gets installed until the end, because
IIRC it doesn't call __objc_install_class_links until that time...

It's really been years since I looked at the runtime so hopefully
someone else may be able to explain it.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]