First, why not have just the NSString versions? Are you working in an environment where Foundation might not/will not be linked? Are these selectors bound to library functions that must take char *’s and you can’t afford the overhead of a second method dispatch or function call (bearing in mind that that just means you’re forcing your API’s consumers to do the conversion before the call themselves, as they’ll likely be working with NSStrings)? If not, don’t have the char * params at all, and take NSString * instead.
But, assuming for the moment that you have a really good reason for such a Cocoa-unfriendly API: “UTF8Name" is highly specific. I’d first consider what your source encoding is (both of the strings that are likely to be passed to this method and of whatever data it’s searching). Do these class names ever even have characters from outside the ASCII character set or could they in the future? “CStringName” is a better name if neither. If they don’t now but might in the future, their representation to your framework may not even be in UTF8 and you’ll just end doing conversions back and forth. Any method that takes a C string without explicitly specifying an encoding in the method name (like "UTF8Name”) really should take an encoding as well. Daniel On Mar 3, 2014, at 3:37 PM, jonat...@mugginsoft.com wrote: > I am pondering the following framework public API method signatures. > > The API requires a mixture of const char* and NSString * parameters. > > The question is whether to precede const char * parameter names with UTF8 > e.g.: > > + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const > char *)assemblyName; > > becomes > > + (MonoClass *)monoClassWithUTF8Name:(char *)className > fromAssemblyUTF8Name:(const char *)assemblyName; > > I have doubts in case that NSString * convenience variants become desirable > in the future. > > Just wondering how others have approached this. > > === > > + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const > char *)assemblyName; > - (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const > char *)name; > + (MonoClass *)monoClassWithName:(char *)className fromAssembly:(MonoAssembly > *)assembly; > + (MonoClass *)corlibMonoClassWithName:(char *)className; > > + (MonoClass *)dubrovnikMonoClassWithName:(char *)className; > + (MonoMethod *)dubrovnikMonoMethodWithName:(char *)methodName > className:(char *)className argCount:(int)argCount; > > - (MonoAssembly *)loadedAssemblyWithName:(const char *)name; > - (MonoAssembly *)loadedAssembly:(NSString *)name; > > - (MonoAssembly *)openAssemblyWithName:(const char *)name; > - (MonoAssembly *)openAssemblyWithPath:(NSString *)assemblyPath; > - (MonoAssembly *)openAssembly:(NSString *)name path:(NSString *)assemblyPath; > - (MonoAssembly *)openAssemblyWithName:(const char *)name path:(NSString > *)path; > > Jonathan > > > > > > > > > > > > > _______________________________________________ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/danhd123%40mac.com > > This email sent to danhd...@mac.com _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
