Re: Is it possible that PreferencePane's share "classes name space"?
Re: Is it possible that PreferencePane's share "classes name space"?
- Subject: Re: Is it possible that PreferencePane's share "classes name space"?
- From: Andrei Tchijov <email@hidden>
- Date: Wed, 6 Sep 2006 11:37:15 -0400
I was just wondering if it is possible to "force" bundle, to look
"inside" itself first when it needs to resolve particular class. I am
fairly sure that it is possible in case of shared libraries and
"normal" functions, I do not see why Objective-C classes and bundles
should be any different.
On Sep 6, 2006, at 11:29 AM, Mailing list subscriptions wrote:
El 06/09/2006, a las 15:13, Andrei Tchijov escribió:
Thanks for the link. It is most certainly very illuminating. I
still can not say that I think that it was good idea on Apple part
to do it the way it was done, but at least now I know exactly what
is going on.
Andrei
Well, there's really no other way it could have been. If an
application (in this case the System Preferences application) loads
a bundle which has a class "foobar", and then you tell it to load
another bundle which also defines a class "foobar", then how is it
supposed to resolve the conflict? This is just the way the
Objective-C runtime works; classnames are in the global namespsace.
Even if Objective-C supported explicit namespaces you'd still have
to modify your source code and tell it that your two "foobar"
classes were in different namespaces.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden