Re: variadic functions missing in bridgesupport file

So this appears to be caused by not having all the .h and .a files for the library and it's dependencies together in the same directories. Eg. I had: /vendor/lib1 /vendor/lib2 /vendor/lib3 when I should have had /vendor/lib3 (containing all of lib1 + lib2 as well) On Mon, 17 Aug

Private Methods

Apple documentation states that the "Names of most private methods in the Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark them as private.” I just ran into a case where one of my method names in a subclass replaced a private Cocoa framework method of the same name ca

Re: Private Methods

> On 18 Aug 2015, at 15:58, Richard Charles wrote: > > Apple documentation states that the "Names of most private methods in the > Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark > them as private.” > > I just ran into a case where one of my method names in a subcl

Re: Private Methods

On 18 Aug 2015, at 16:58, Richard Charles wrote: > Also why does Apple say "If you are subclassing a large Cocoa framework > class”. What if I am subclassing a small Cocoa framework class. What > difference would it make? Statistics. Small classes probably only consist of the public API, or m

Re: Private Methods

On Tue, 18 Aug 2015 08:58:22 -0600, Richard Charles said: >Apple documentation states that the "Names of most private methods in >the Cocoa frameworks have an underscore prefix (for example, _fooData ) >to mark them as private.” > >I just ran into a case where one of my method names in a subclass

Re: Private Methods

Hence the long traditional advice to do one or both of two things. Remember Objective-C has no namespaces. Prefix everything with your own identifier. Don't use short simple obvious names. There are many reasons Cocoa tends to be verbose. This is one. An added bonus of prefixes is that they

Re: Private Methods

> On Aug 18, 2015, at 9:01 AM, Mike Abdullah wrote: > > Go on, satisfy our curiosity, what did you accidentally override? I made a CAOpenGLLayer subclass “context” property for use with OpenGL context sharing but CALayer has a private “context” property. So yes CALayer would constitute a larg

Re: Private Methods

My own preference is to prefix private methods with underscores and the project’s class prefix. For example, from source code of WebUIKit (class prefix CGI, taken from its parent project CGIKit): NSString *const k_CGI_PrivateMemberAttribute; @interface CGIView () + (id)_CGI_superviewWithClass:

Xcode warning from linking to a third-party framework in both app and in framework included in app?

I'm linking to the Parse.com frameworks in both my app and in a private framework of my own included in the app. This generates the linker warning below. Both the app and the included framework use objc[1735]: Class PFObject is implemented in both and . One of the two will be used. Which one i

Re: Private Methods

On Tue, 18 Aug 2015 23:23:00 +0800, Maxthon Chan said: >My own preference is to prefix private methods with underscores and the >project’s class prefix. That's exactly what you should not do. Like the OP said, Apple's docs say that they reserve things starting with underscore for themselves. A

Thread-safe singleton with lazy initialisation

Is this the proper way to initialise a singleton object in a thread-safe manner? A little bit background, I am rewriting my CGIKit Web development framework for Objective-C and now Swift, and after the idea of building the Web application into a loadable bundle that either a FastCGI-speaking cgi

Re: Thread-safe singleton with lazy initialisation

Il giorno 18/ago/2015, alle ore 18:00, Maxthon Chan ha scritto: > > So the first class that is required is the main application class > CGIApplication. Being the analogue of UIApplication it is a singleton. Is > this the proper way of doing it? I cannot use @synchronized yet because there > i

Re: Thread-safe singleton with lazy initialisation

Two questions: 1) How good will a Mac hold up as a server? I can serve static content from the CDN I rented but CGIKit code is dynamic stuff. If a Mac and OS X holds well, I can throw Linux compatibility out of the window and use GCD as I will. 2) If a Mac does not fare well as a server, I will

Re: Thread-safe singleton with lazy initialisation

Two questions: 1) How good will a Mac hold up as a server? I can serve static content from the CDN I rented but CGIKit code is dynamic stuff. If a Mac and OS X holds well, I can throw Linux compatibility out of the window and use GCD as I will. 2) If a Mac does not fare well as a server, I will

Re: Private Methods

> On Aug 18, 2015, at 9:27 AM, Sean McBride wrote: > > You can set the OBJC_PRINT_REPLACED_METHODS env var to help catch conflicts. OBJC_PRINT_REPLACED_METHODS logs methods replaced by category implementations. If the replaced method is not in a category then it does not work. :-( --Richard C

Re: Private Methods

> On Aug 18, 2015, at 9:53 AM, Richard Charles wrote: > > OBJC_PRINT_REPLACED_METHODS logs methods replaced by category > implementations. If the replaced method is not in a category then it does not > work. :-( Yeah, there’s no way for the runtime to tell the difference between an ‘expected

Re: Xcode warning from linking to a third-party framework in both app and in framework included in app?

> On Aug 18, 2015, at 8:48 AM, Steve Mykytyn wrote: > > I'm linking to the Parse.com frameworks in both my app > and in a private > framework of my own included in the app. This generates the linker warning > below. If Parse provides their library in the form of a true (dy

Re: Private Methods

On Aug 18, 2015, at 10:20 , Jens Alfke wrote: > > But would Swift have caught this issue, since the CALayer.context property > isn’t visible in headers at all, only in the compiled code? I don’t actually know (it’s a bit awkward to test), but my belief is that Swift does not have this defect.

Re: Private Methods

> On Aug 18, 2015, at 11:20 AM, Jens Alfke wrote: > > Yeah, there’s no way for the runtime to tell the difference between an > ‘expected’ method override and an ‘unexpected’ one. How about an annotation for the compiler. Something like _Override or _NSOverride where you declare your intent to

Re: Private Methods

The compiler knows absolutely NOTHING. It is up to the runtime to determine which implementation to call when a message is sent. This is the dynamic nature of Objective-C. > On Aug 19, 2015, at 02:28, Richard Charles wrote: > > >> On Aug 18, 2015, at 11:20 AM, Jens Alfke wrote: >> >> Yeah,

Re: Thread-safe singleton with lazy initialisation

A couple of things: you can > On Aug 18, 2015, at 9:29 AM, Maxthon Chan wrote: > > Two questions: > > 1) How good will a Mac hold up as a server? I can serve static content from > the CDN I rented but CGIKit code is dynamic stuff. If a Mac and OS X holds > well, I can throw Linux compatibilit

Re: Private Methods

> On Aug 18, 2015, at 11:32 AM, Maxthon Chan wrote: > > The compiler knows absolutely NOTHING. The (Obj-C) compiler knows if a superclass declares a method with the same selector. So in some cases it can tell that you’re overriding. The problem is that it can’t tell if your method overrides a

Re: Private Methods

> On Aug 18, 2015, at 12:20 PM, Jens Alfke wrote: > > But would Swift have caught this issue, since the CALayer.context property > isn’t visible in headers at all, only in the compiled code? Jens Alfke, of mooseyard.com , has presented us with a poser. We do not know whi

Re: Thread-safe singleton with lazy initialisation

> On Aug 18, 2015, at 9:29 AM, Maxthon Chan wrote: > > Two questions: > > 1) How good will a Mac hold up as a server? I can serve static content from > the CDN I rented but CGIKit code is dynamic stuff. If a Mac and OS X holds > well, I can throw Linux compatibility out of the window and use

Re: Constraints across sibling stack views?

> On Aug 17, 2015, at 9:57 AM, David Duncan wrote: > >> What's the proper way to have these labels all equal width, when they're in >> different NSStackViews? > > Do you mean for the label to be equal width to another label (although it > shouldn’t matter, but I just want to make sure I unders

Re: Private Methods

On Aug 18, 2015, at 12:07 , Charles Srstka wrote: > >> On Aug 18, 2015, at 12:20 PM, Jens Alfke > > wrote: >> >> But would Swift have caught this issue, since the CALayer.context property >> isn’t visible in headers at all, only in the compiled code? > > Jens Alfke,

Re: Nullability annotation "best practice"

On Aug 16, 2015, at 11:13 AM, Kevin Meaney wrote: > I’ve annotated the public methods of the API of a framework and though I > haven’t yet I will annotate internal methods and functions as well. > > I found a small number of issues where my thinking had not been clear, and > that having to sto

Re: Private Methods

Well, the lack of adhering to that very principle was what caused my confusion with UIStoryboard the other day. None of the private methods followed this. Sent from my iPhone > On Aug 18, 2015, at 10:58 AM, Richard Charles wrote: > > Apple documentation states that the "Names of most private

Re: Private Methods

> On Aug 18, 2015, at 3:36 PM, Quincey Morris > wrote: > > On Aug 18, 2015, at 12:07 , Charles Srstka > wrote: >> >>> On Aug 18, 2015, at 12:20 PM, Jens Alfke >> > wrote: >>> >>> But would Swift have caught this issue, since the CALa

Re: Private Methods

On Aug 18, 2015, at 14:50 , Charles Srstka wrote: > > Look a little closer, and you’ll notice that the app code was in Swift (like > your app would be), and the framework code was in Objective-C (like the > Foundation/AppKit classes are). Actually, I did look, but obviously I did not see. But

Re: Private Methods

> On Aug 18, 2015, at 5:19 PM, Quincey Morris > wrote: > > But, in my own defense, I was looking for verification first that the > mechanism is safe in 100% pure Swift. The next thing to verify is whether > it’s safe with an @objc base class in Swift. Only if both those things are > safe does

Re: Private Methods

On Aug 18, 2015, at 15:48 , Charles Srstka wrote: > > Currently, the Swift runtime hasn’t stabilized yet, and it’s pretty unlikely > that any system frameworks will be written in it until it is. The bigger issue, I think, is that apps using Cocoa APIs have to continue to run against existing C

Re: Private Methods

> On Aug 18, 2015, at 5:19 PM, Quincey Morris > wrote: > > But, in my own defense, I was looking for verification first that the > mechanism is safe in 100% pure Swift. The next thing to verify is whether > it’s safe with an @objc base class in Swift. Only if both those things are > safe does

Re: Xcode warning from linking to a third-party framework in both app and in framework included in app?

Turns out the way to handle this seems to be: 1. Use an Other Linker Flag: "-weak_framework Parse" in the private framework target 2. Don't link to Parse in the Linker Build phase in the private framework target 3. Link as normal to Parse in the main app target. Clean the build folders all aro

Re: Private Methods

On Aug 18, 2015, at 15:48 , Charles Srstka wrote: > > If bar() is declared as private instead of internal, the library’s copy of > bar gets called each time The most likely difference resulting from that is that private bar can be inferred to be ‘final’, whereas I’m not sure that internal bar

Re: Private Methods

On Aug 18, 2015, at 6:22 PM, Quincey Morris wrote: > > On Aug 18, 2015, at 15:48 , Charles Srstka > wrote: >> >> If bar() is declared as private instead of internal, the library’s copy of >> bar gets called each time > > The most likely difference resulting f

3rd party framework crashes with invalid code sign

We have a weird problem after upgrading to Yosamite: We use a 3rd party framework and codesign it on copying in Build Phases. When we run the application (which is LSUIElement - agent application) sometimes after it crashes with the following crash report and the user cannot run it again anymo

Swift: 'If' statement needing parentheses on closure return value property access?

In Swift 2.0 I can write this: repeat { … } while reminder.exclusions.filter { $0.spansTime(t) }.count > 0 but I can’t write this: if reminder.exclusions.filter { $0.spansTime(t) }.count > 0 { … } which gives an erro

Re: Swift: 'If' statement needing parentheses on closure return value property access?

Maybe file a bug to see if it's expected. But at first glance it seems clear to be ambiguous scope. it can't figure out that the first {} is part of the condition rather than the thing triggered by the condition. A do while knows more easily because the {} after do is what is conditionally ex

Re: Swift: 'If' statement needing parentheses on closure return value property access?

Clearly it’s a “more ambiguous” context than the while case, which prevents the compiler from realizing that there is an alternative analysis that works. In that case, it’s the error message that’s at fault, since it doesn’t really tell you what’s wrong. In fact, this “consecutive statements” er