On 3 Mar 2014, at 19:23, Kyle Sluder wrote:
> But Jonathan, why are you even exposing raw C pointer access to the
> identifiers in the first place? Why wouldn't you convert them to
> NSStrings and only expose them to Objective-C code that way?
>
Jens sort of nailed it.
The underlying Mono API i
On Mon, Mar 3, 2014, at 09:54 AM, Daniel DeCovnick wrote:
> Given that, UTF8Name actually sounds fine.
No it doesn't. There's nothing in Jonathan's links to suggest that the
CLS specifies that identifiers are stored in UTF-8 encoding. In fact, it
implies otherwise:
"""Before you compare identifi
On Mar 3, 2014, at 5:09 PM, jonat...@mugginsoft.com wrote:
>
> Hmm.That’s a good point. I was hung up on the Cocoa side of things.
>
> Commonly the char *strings represent a C# identifier
> http://msdn.microsoft.com/en-us/library/aa664670.aspx
> The rules for identifiers given in this section
On 03 Mar 2014, at 17:09, jonat...@mugginsoft.com wrote:
> Commonly the char *strings represent a C# identifier
> http://msdn.microsoft.com/en-us/library/aa664670.aspx
I can't answer this for you, but should it even be exposed in the API that it
is a string? Think of SEL. Under the hood, it is
Sure, but the consumer of the framework is still an Objective-C application or
framework, which is going to be using NSStrings for everything else already and
presumably up to the boundary with this framework. Why make the consumer do the
conversion? If the method is going to be called “a lot”,
On Mar 3, 2014, at 7:19 AM, Daniel DeCovnick wrote:
> 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
The OP is working with Mono, a C# runtime, so I’m sure the glue to it takes C
strings.
On 3 Mar 2014, at 15:19, Daniel DeCovnick wrote:
> 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
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 wrote:
> First, why not have just the NSString versions?
>
> Are you working in an environment where Foundation
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 min
I would say that adding UTF8 to the method names implies that the framework
expects UTF8, if that's true, that's a good method name.
If you want to support other encodings then a method name which takes a char*
and an encoding would be better, still including a UTF8 version which just
calls th
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 cha
11 matches
Mail list logo
