Re: Modules in Objective-C like e.g. OSGi-Bundles in Java
Re: Modules in Objective-C like e.g. OSGi-Bundles in Java
- Subject: Re: Modules in Objective-C like e.g. OSGi-Bundles in Java
- From: Jonathan deWerd <email@hidden>
- Date: Thu, 7 Aug 2008 14:30:11 -0600
On Aug 7, 2008, at 1:45 PM, Matthias Luebken wrote:
Hi
I'm new to Cocoa and Objective-C. Please point me to a different group
/ forum if this mailing-list isn't appropriate.
I have a fairly basic language question: Is there a module concept in
Objective-C / Cocoa? I'm thinking in terms of OSGi bundles[0]. What
would I do if I would like to encapsulate a certain functionality that
consists of several classes? Could I define an API how to use this
module and make sure private classes of this module aren't visible to
the outside?
Thanks in advance.
Looking forward to learn Obj-C and Cocoa
Matthias
[0] http://www.osgi.org/About/Technology#Framework
No, there is no module system in ObjC, and there is no concrete way to
make methods private. We believe in convention over regulation: it
makes dealing with exceptional cases that much easier.
Class names are prefixed by (usually) two letter codes that identify
the developer or the project. These are remarkably effective at
avoiding name conflicts, the idea being that if your identifier +
classname isn't unique then you should really be extending the other
person's class or renaming yours more specifically. If you were really
pedantic I guess you might even give your classes a reverse DNS prefix
and use macros for convenience.
Similarly, there are no private methods. Convention, however, makes
anything starting with underscores private. You can also add a
category whose interface is only visible inside your implementation
file. That being said, if you really really want private methods, I
would suggest defining C-like functions (static, inline, or prefixed
with the class name to avoid conflict) inside your @implementation:
they can access private variables without warning, like so:
@interface FooClass : NSObject {
int _myVariable;
}
- (void)plusPlus;
@end
//In your .m or .mm file
@implementation FooClass
inline incrementVariable(FooClass* self, int incBy) {
self->_myVariable += incBy;
}
- (void)plusPlus {
incrementVariable(self,1);
}
@end
The overriding philosophy here is that a little verbosity
simultaneously avoids conflicts and makes code more understandable,
while not significantly impacting typing time (this is the age of auto-
complete and tab-triggers, after all). If you're trying to implement a
security system (ala OSGi) that tries to sequester code within a
native process, you're playing a loosing game: since the process is
native, every piece of code has access (however indirect) to every
piece of memory and code within the process. If you really wanted to,
you might be able to mess with the EMMI (see the Kernel Programming
Guide) enough to change that, but it'd be a chore.
In the OSX (and UNIX) security model, you sandbox things at the
process level. If you want your program to make a privileged
modification of the system, for instance, you would probably make a
small command line utility and include it in your app. You then
authorize the utility (through the infamous lock dialog) and call it
from your program to do what you want. You might use IPC (through mach
or the cocoa IPC mechanism) if you need to control a multi-step
privileged subprogram.
If you want to run constrained plugins, you might look into a
scripting language that was designed for such considerations, and
provide proxies that only allow access to certain parts of the parent
program.
Sorry if I got derailed on security: your message does'n mention it
but your link does. In any case, I hope this information was helpful.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden