Forgot to add, if your framework *does* expect and will continue to expect UTF8 strings, then yes, “UTF8Name” is a fine choice.
Daniel On Mar 3, 2014, at 4:19 PM, Daniel DeCovnick <[email protected]> wrote: > 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, [email protected] 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 ([email protected]) >> >> 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 [email protected] > > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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 [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
