On 17 Nov 2009, at 08:59, Motti Shneor wrote: > First, to clear things, I'm not WRITING plug-ins. I'm transitioning our > EXISTING product line from Carbon to Cocoa, to be able to run within 64bit > Host applications (which, do not exist yet.). Within this scope, I > contemplate the way to re-package our deployed "plug-in" entities and other > frameworks with Obj-C wrappers.
I understand that. So does everyone else. We also understand that your code base is large and that you don't want to change every existing class name or redesign your build system on every platform. But nothing anyone has said so far requires that you do any of those things. If you think you do, it's because you are labouring under some misunderstanding about Cocoa/ObjC. All we're saying is that *for your ObjC classes*, you need the names to be unique across your entire process, and in practice that means prepending them with something. For a plug-in system, especially if it plugs in to code in a third-party process, I strongly recommend that you use something akin to Java's reverse domain scheme, even though, as I say, that isn't the usual solution for Objective-C code. I don't see why that would require the kind of changes you're indicating it would. > I must be sure that when a plug refers to the base framework, It'll use the > exact version it linked agains, and was tested to work with. Right. Yes, it will. The framework versioning mechanism is just a variation on the usual symlink system used on most UNIX-like systems for shared libraries. The only difference is that the structure is not flat (so whereas you might see e.g. "libcrypto.dylib" symlinked to "libcrypto.0.9.8.dylib", here it's the folders that are symlinked). >> On 16/11/2009, at 18:58, Alastair Houghton wrote: >> >> Moreover, Cocoa provides such API (mainBundle) for applications, which makes >> perfect sense to everyone. How is it that ONLY application bundles support >> this API? After all, every code bundle is structured the same, and includes >> resources etc. >> >> It *isn't* only application bundles that support it. It works just fine >> with *any* bundle. But the -bundleForClass: method assumes (as does the >> rest of the ObjC runtime) that each ObjC class has a unique name. > > I double-checked it, and you're wrong. Ah, sorry, I see what you meant---you were talking specifically about the -mainBundle method itself. I had misunderstood your sentence (I think perhaps a language issue---a native English speaker would probably have used "this" rather than "such", which has a somewhat different meaning here). > When my plug-in bundle is loaded by the host application, and some of my code > is being called if it uses the [NSBundle mainBundle]; API it will get the > application bundle, not its own bundle. There is no generic API for any > running code to ask "what is MY bundle". Only applications can do that. As you've been told already, you need -bundleForClass:. The problem you are having with it is because you're misusing the Objective-C language and runtime, and you're doing that---you claim---because for some reason your Objective-C class names can't possibly be prepended with a unique identifier for each plug-in. Quite frankly, I don't buy it; it shouldn't require changes to the build system on all your other platforms to achieve that, and it isn't complicated. Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
