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 2015 at 21:04 Lee Henson lee.m.hen...@gmail.com wrote: Hi I'm trying to use gen_bridge_metadata to create a bridgesupport file for a c library that contains a mixture of variadic and non-variadic functions. The non-variadic functions appear in the bridgesupport xml, but the variadic functions do not. Is this a known limitation? It looks to me like gen_bridge_metadata has some code that mentions variadic functions, but bridgesupportparse.parse does not detect them so they are never logged in the xml. Any advice gratefully received! Cheers Lee ___ 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
Re: Private Methods
On Aug 18, 2015, at 9:53 AM, Richard Charles rcharles...@gmail.com 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’ method override and an ‘unexpected’ one. This is one of the reasons a lot of newer languages (like Swift) make you add an explicit “override” keyword to an overridden method declaration. That way the compiler and/or runtime can detect an unexpected override and issue an error. 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 ___ 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
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 rcharles...@gmail.com wrote: On Aug 18, 2015, at 11:20 AM, Jens Alfke j...@mooseyard.com 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 intentionally override a method or property. Does the compiler know about Objective-C method or property overrides? --Richard Charles ___ 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/max%40maxchan.info This email sent to m...@maxchan.info smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: Private Methods
On Aug 18, 2015, at 10:20 , Jens Alfke j...@mooseyard.com 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. Conflicts within a module would be caught at link time, and conflicts across a module boundary can’t happen because of namespacing — by definition, your apparently-conflicting method name is in a different module. However, it’s not obvious to me whether this works when the “base” module is an Obj-C framework such as Cocoa frameworks. In that case, it seems possible that the Obj-C mechanics of dynamic overrides might force Swift to use the older unsafe mechanism. I don’t know that I’ve seen this discussed in the forums, but it would be nice to know the answer. ___ 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
Re: Private Methods
On Aug 18, 2015, at 11:32 AM, Maxthon Chan m...@maxchan.info 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 _non-public_ method in a superclass. That information is only in the superclass’s compiled code, not in the headers, so it isn’t available at compile time. (And it’s possible for the superclass method to be added at runtime, in which case not even the framework binary would show that exists!) It would be possible to add an “override” flag to the method metadata; then when a class is being loaded the runtime could check whether it has a method without that flag that will actually override a superclass method, and if so signal some sort of failure. This won’t catch the cases where methods get inserted into the superclass after the subclass is loaded, but it will catch the most common causes of problems. —Jens ___ 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
Re: Private Methods
On Aug 18, 2015, at 12:20 PM, Jens Alfke j...@mooseyard.com 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 http://mooseyard.com/, has presented us with a
poser. We do not know which bush the private method is behind. But we can soon
find out.
MyBaseClass.h in framework:
#import Foundation/Foundation.h
@interface MyBaseClass : NSObject
- (void)foo;
@end
MyBaseClass.m in framework:
#import MyBaseClass.h
@implementation MyBaseClass
- (void)foo {
fprintf(stderr, “BOOM!\n);
}
@end
App:
import MyFramework
class MyClass: MyBaseClass {
func bar() {
print(“BLEAH!)
}
}
let obj = MyClass()
obj.foo()
Output:
BOOM!
New MyBaseClass.m:
#import MyBaseClass.h
@implementation MyBaseClass
- (void)foo {
fprintf(stderr, BOOM!\n);
[self bar];
}
- (void)bar {
fprintf(stderr, Bar called in framework\n);
}
@end
Output without recompiling the app:
BOOM!
BLEAH!
Output after recompiling the app:
No compiler errors, then:
BOOM!
BLEAH!
Yes, it was the middle one. (And also the one on the right.)
Charles
___
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
Re: Private Methods
On Aug 18, 2015, at 11:20 AM, Jens Alfke j...@mooseyard.com 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 intentionally override a method or property. Does the compiler know about Objective-C method or property overrides? --Richard Charles ___ 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
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 smyky...@gmail.com wrote: I'm linking to the Parse.com http://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 (dynamic) framework, you should use that and have both your app and your private framework link against it. If they only provide a static framework/library, you can create a target that builds that into a dynamic framework and exports the necessary symbols, then do the above. —Jens ___ 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
Re: Thread-safe singleton with lazy initialisation
A couple of things: you can
On Aug 18, 2015, at 9:29 AM, Maxthon Chan m...@maxchan.info 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 GCD as I will.
2) If a Mac does not fare well as a server, I will have to make sure my code
is compatible with GNUstep which is the best Cocoa clone for Linux I have
encountered so far - complete with ARC and Blocks but GCD support on GNUstep
is poor (and CoreFoundation support is spotty) so I have to avoid using GCD
completely and use CoreFoundation only sparsely.
On Aug 19, 2015, at 00:18, Simone Tellini cocoa-...@tellini.info
mailto:cocoa-...@tellini.info wrote:
Il giorno 18/ago/2015, alle ore 18:00, Maxthon Chan m...@maxchan.info 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 is nothing to lock on:
if you used GCD, it would be simpler:
+ (instancetype)sharedInstance
{
static dispatch_once_t once;
static id ret;
dispatch_once( once, ^{
ret = [[self alloc] init];
} );
return ret;
}
--
Simone Tellini
http://tellini.infoIs 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 cgikitd or
an Apache module mod_objc went up in smoke due to opening up serious security
bugs and lifecycle management issues, I am going back to the path of building
the Web application into an executable, now speaking FastCGI but not launched
by the Web server.
I am modelling the HTTP protocol layer (CGIKit) after ASP.net
http://asp.net/ and the Web layer (WebUIKit) after UIKit using bits and
pieces from Bootstrap+jQuery (which itself is just a big CSS+JS file) as
“controls”. However due to the fact that FastCGI event loop being part of the
protocol some CGIApplication (analogue of UIApplication) have to be placed in
CGIKit. UIKit’s non-atomic-ness is dropped and all operation have to be
atomic, since Web servers are expected to process multiple requests at the
same time.
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
is nothing to lock on:
#import pthread.h
pthread_mutex_t _CGI_ApplicationStartingMutex;
@implementation CGIApplication
+ (void)initialize
{
pthread_mutex_init(_CGI_ApplicationStartingMutex, NULL);
}
+ (instancetype)sharedApplication
{
if (!CGIApp)
{
pthread_mutex_lock(_CGI_ApplicationStartingMutex);
if (!CGIApp)
{
CGIApp = [[CGIApplication alloc] init];
}
pthread_mutex_unlock(_CGI_ApplicationStartingMutex);
}
return CGIApp;
}
@end___
___
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
Re: Private Methods
On Aug 18, 2015, at 9:27 AM, Sean McBride s...@rogue-research.com 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 Charles ___ 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
Re: Private Methods
On Aug 18, 2015, at 12:07 , Charles Srstka cocoa...@charlessoft.com wrote: On Aug 18, 2015, at 12:20 PM, Jens Alfke j...@mooseyard.com mailto:j...@mooseyard.com 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 http://mooseyard.com/ http://mooseyard.com/ http://mooseyard.com/, has presented us with a poser. We do not know which bush the private method is behind. But we can soon find out. I’m confused. We already knew the answer to the test you did — if it was anything else, this thread wouldn’t have ever existed. Jens’s poser was a question about Swift. Have you tried the same test in Swift? ___ 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
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 rcharles...@gmail.com 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 subclass replaced a private Cocoa framework method of the same name causing my application to crash in the next version of OS X. The private Cocoa framework method name did not have an underscore prefix. So the documentation is correct, “most” but not all private methods in the frameworks have an underscore prefix. There is no way that I would have known about the private Cocoa framework method except examining a class-dump. Apple documentation also states that If you are subclassing a large Cocoa framework class (such as NSView or UIView) and you want to be absolutely sure that your private methods have names different from those in the superclass, you can add your own prefix to your private methods. The prefix should be as unique as possible, perhaps one based on your company or project and of the form XX_. So if your project is called Byte Flogger, the prefix might be BF_addObject: I have never bothered doing this because for one reason BF_addObject looks so ugly as a method name. Does anyone prefix their private method names like Apple recommends when subclassing a large Cocoa framework class? 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? --Richard Charles ___ 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/zav%40mac.com This email sent to z...@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
Re: Nullability annotation best practice
On Aug 16, 2015, at 11:13 AM, Kevin Meaney k...@yvs.eu.com 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 stop and consider what was intended when annotating the public API for nullability exposed my lack of clarity. I did not have any recorded bugs in this case but I could see how the API could be used that would result in bugs, crashing or otherwise. I added annotations to both the public and private sides of a core framework that's about 17,000 lines of code, and I had the same experiences. On both sides, while 97% of it was clear cut, there was a small number of cases where I wasn't really sure what the answer to nullability and knock on effects was. If I say this public function returns non-null, how sure of that am I really? In a few places I really had to go digging and verify that every step along the way ensured that result. Like you, I don't believe I caught any current bugs, but it clarified my thinking, and showed potential edge cases in the future which could have resulted in problems that now would be caught by the compiler. Although it was tedious to add those annotations and validate them (it only took half a day or so), I feel better for having done it. -- Seth Willits ___ 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
Re: Thread-safe singleton with lazy initialisation
On Aug 18, 2015, at 9:29 AM, Maxthon Chan m...@maxchan.info 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 GCD as I will. 2) If a Mac does not fare well as a server, I will have to make sure my code is compatible with GNUstep which is the best Cocoa clone for Linux I have encountered so far - complete with ARC and Blocks but GCD support on GNUstep is poor (and CoreFoundation support is spotty) so I have to avoid using GCD completely and use CoreFoundation only sparsely. Apple's Objective-C runtime provides thread-safety guarantees for +initialize. If you are on some other platform then you should check if that platform provides similar guarantees. dispatch_once() is the best solution on Apple's platforms. If you don't like dispatch_once() then you could use pthread_once(). If you don't like dispatch_once() nor pthread_once() then you can use PTHREAD_MUTEX_INITIALIZER instead of pthread_mutex_init(). That avoids any questions of +initialize thread-safety. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
Re: Private Methods
On Aug 18, 2015, at 14:50 , Charles Srstka cocoa...@charlessoft.com 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, 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 it make any sense to wonder if an Obj-C base class is safe. However, the test you did doesn’t give much cause for optimism. I suppose *selectors* would have to be namespaced to solve the problem for the Obj-C runtime, wouldn’t it? For compatibility reasons, that seems unlikely, which makes it unlikely that this problem will ever be solved for Cocoa frameworks. ___ 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
Re: Constraints across sibling stack views?
On Aug 17, 2015, at 9:57 AM, David Duncan david.dun...@apple.com 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 understand from your pictures)? I would expect that to work generically, but I don’t have any particular insight into why it might not. If that fails, you might try doing 2 vertical stacks and using baseline alignments across the vertical stack views instead... Thanks for the response. I took another look to try your suggestion, and it turns out I managed to get it to work both ways. It seems like the warnings I was getting were just sticky leftovers that weren't actually real. After saving, closing the xib, clean building, and reopening the xib everything is fine. So either two vertical stacks, or a vertical stack of three horizontal stacks, either works just fine. http://www.sethwillits.com/temp/upshot/upshot_taR2gwwa.png All is good! -- Seth Willits ___ 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
Re: Private Methods
On Aug 18, 2015, at 3:36 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Aug 18, 2015, at 12:07 , Charles Srstka cocoa...@charlessoft.com mailto:cocoa...@charlessoft.com wrote: On Aug 18, 2015, at 12:20 PM, Jens Alfke j...@mooseyard.com mailto:j...@mooseyard.com 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 http://mooseyard.com/ http://mooseyard.com/ http://mooseyard.com/, has presented us with a poser. We do not know which bush the private method is behind. But we can soon find out. I’m confused. We already knew the answer to the test you did — if it was anything else, this thread wouldn’t have ever existed. Jens’s poser was a question about Swift. Have you tried the same test in Swift? 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). Charles ___ 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
Re: Private Methods
On Aug 18, 2015, at 5:19 PM, Quincey Morris
quinceymor...@rivergatesoftware.com 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 it make any sense to wonder if an Obj-C base class is safe.
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. So currently,
you’re going to be recompiling everything every time, and your code will all
have access to all Swift methods, public and private. So with pure Swift, it
shouldn’t be an issue one way or another until Apple starts shipping a Swift
runtime with the OS, at which point we can do a new test.
…oh heck, let’s test it now.
Framework code:
import Foundation
public class BaseClass {
public init() {}
public func foo() {
print(Foo called in library)
}
}
App code:
import MyFramework
class DerivedClass: BaseClass {
func bar() {
print(Bar called in app)
}
}
let obj = DerivedClass()
obj.foo()
Output:
Foo called in library
New framework code:
public class BaseClass {
public init() {}
public func foo() {
print(Foo called in library)
self.bar()
}
internal func bar() {
print(Bar called in library)
}
}
Results without recompiling:
Foo called in library
Bar called in app
Wat.
Results after a recompile look okay:
Foo called in library
Bar called in library
However, for more fun times, I tried deleting bar() from BaseClass and running
the app again without recompiling. I got:
dyld: Symbol not found: __TFC11MyFramework9BaseClass3barfS0_FT_T_
Referenced from:
/Users/###REDACTED###/Library/Developer/Xcode/DerivedData/build/Products/Debug/new
test.app/Contents/MacOS/new test
Expected in:
/Users/###REDACTED###/Library/Developer/Xcode/DerivedData/build/Products/Debug/MyFramework.framework/Versions/A/MyFramework
in
/Users/###REDACTED###/Library/Developer/Xcode/DerivedData/build/Products/Debug/new
test.app/Contents/MacOS/new test
If bar() is declared as private instead of internal, the library’s copy of bar
gets called each time, but the crash still happens if I remove the method from
the framework without recompiling the app.
So, in summary: Swift doesn’t fix the problem Objective-C has, and it adds a
new one.
However, the test you did doesn’t give much cause for optimism. I suppose
*selectors* would have to be namespaced to solve the problem for the Obj-C
runtime, wouldn’t it? For compatibility reasons, that seems unlikely, which
makes it unlikely that this problem will ever be solved for Cocoa frameworks.
You could do something like @objc(MyObnoxiousPrefix_foo), and if you were only
going to call it from Swift anyway, it wouldn’t ugly up your code at all. The
problem above would still remain, of course (although in all seriousness, I’d
be kinda surprised if it stayed that way - Swift is clearly still in formative
stages).
Charles
___
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
Re: Private Methods
On Aug 18, 2015, at 15:48 , Charles Srstka cocoa...@charlessoft.com 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 Cocoa frameworks. If this means that Cocoa frameworks can’t be modularized/namespaced, then there’ll never be a solution to Richard’s “context” problem. Note that the above statement doesn’t mention language at all. It’s an ABI compatibility problem, and I was apparently too naive in hoping that the advent of Swift would bring a solution to that problem. On Aug 18, 2015, at 15:19 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: Actually, I did look, but obviously I did not see. This is the second time in a week I’ve looked at code and failed to distinguish which language it was written in. This is a little worrying. Are we going to have to have public service announcements for developers converting to Swift? (“This is your brain. This is your brain on Swift.”) ___ 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
Re: Private Methods
On Aug 18, 2015, at 5:19 PM, Quincey Morris
quinceymor...@rivergatesoftware.com 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 it make any sense to wonder if an Obj-C base class is safe.
However, the test you did doesn’t give much cause for optimism. I suppose
*selectors* would have to be namespaced to solve the problem for the Obj-C
runtime, wouldn’t it? For compatibility reasons, that seems unlikely, which
makes it unlikely that this problem will ever be solved for Cocoa frameworks.
Hey, you know what *does* work? Going back to the original test:
MyBaseClass.h:
#import Foundation/Foundation.h
@interface MyBaseClass : NSObject
- (void)foo;
@end
MyBaseClass.m (initially):
@implementation MyBaseClass
- (void)foo {
fprintf(stderr, BOOM!\n);
}
@end
App code:
import MyFramework
class MyClass: MyBaseClass {
@nonobjc func bar() {
print(BLEAH!)
}
}
let obj = MyClass()
obj.foo()
Output:
BOOM!
MyBaseClass.m changed to:
#import MyBaseClass.h
@implementation MyBaseClass
- (void)foo {
fprintf(stderr, BOOM!\n);
[self bar];
}
- (void)bar {
fprintf(stderr, It actually succeeded at Not Being Seen\n);
}
@end
Output without recompiling:
BOOM!
It actually succeeded at Not Being Seen
Output after recompiling the app:
BOOM!
It actually succeeded at Not Being Seen
And reverting MyBaseClass.m to the original and not recompiling the app:
BOOM!
So, if you declare all your new methods as @nonobjc and the base class remains
written in Objective-C, any new private method added to the base class will be
concealed extremely well.
However, we happen to know, it's in the water barrel. (“BOOM!”)
Charles
___
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
Re: Private Methods
On Aug 18, 2015, at 15:48 , Charles Srstka cocoa...@charlessoft.com 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 gets anything inferred (currently) without whole-module optimization turned on. So maybe the results you're seeing (in the other test, too, perhaps) reflect the difference between dynamic dispatch and static call, rather than some other (hypothetical) mechanism that keeps method names separate across module boundaries. ___ 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
Re: Private Methods
On Aug 18, 2015, at 6:22 PM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Aug 18, 2015, at 15:48 , Charles Srstka cocoa...@charlessoft.com
mailto:cocoa...@charlessoft.com 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 gets anything
inferred (currently) without whole-module optimization turned on.
So maybe the results you're seeing (in the other test, too, perhaps) reflect
the difference between dynamic dispatch and static call, rather than some
other (hypothetical) mechanism that keeps method names separate across module
boundaries.
Nope, I think I’ve figured out what was going on, and it’s much simpler than
either of those things:
Framework code:
public class BaseClass {
public init() {}
public func foo() {
print(Foo called in library)
}
}
App code:
import MyFramework
class DerivedClass: BaseClass {
func bar() {
print(Bar called in app)
}
}
let obj = DerivedClass()
obj.foo()
New framework code:
public class BaseClass {
public init() {}
public func foo() {
print(Foo called in library)
self.definitelyNotBar()
}
internal func definitelyNotBar() {
print(definitelyNotBar called in library)
}
}
Output:
Foo called in library
Bar called in app
Yep, we’ve re-invented the base class problem.
Charles
___
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
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 around, do the builds and the warnings are all gone. At least on Xcode 6.4... On Tue, Aug 18, 2015 at 10:23 AM, Jens Alfke j...@mooseyard.com wrote: On Aug 18, 2015, at 8:48 AM, Steve Mykytyn smyky...@gmail.com wrote: I'm linking to the Parse.com http://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 (dynamic) framework, you should use that and have both your app and your private framework link against it. If they only provide a static framework/library, you can create a target that builds that into a dynamic framework and exports the necessary symbols, then do the above. —Jens ___ 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
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 anymore : Exception Type:EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0002, 0x Application Specific Information: dyld: launch, loading dependent libraries Dyld Error Message: Library not loaded: @executable_path/../Frameworks/TspSdk.framework/Versions/A/TspSdk Referenced from: /Users/USER/Desktop/Test1.app/Contents/MacOS/Test Reason: no suitable image found. Did find: /Users/myuser/Desktop/Test1.app/Contents/MacOS/../Frameworks/TspSdk.framework/Versions/A/TspSdk: code signature invalid for '/Users/myuser/Desktop/Test1.app/Contents/MacOS/../Frameworks/TspSdk.framework/Versions/A/TspSdk' /Users/myuser/Desktop/Test1.app/Contents/MacOS/../Frameworks/TspSdk.framework/Versions/A/TspSdk: code signature invalid for '/Users/myuser/Desktop/Test1.app/Contents/MacOS/../Frameworks/TspSdk.framework/Versions/A/TspSdk' Invoking codesign from terminal on this framework returns valid results, but nevertheless we get this crash on trying to run the application... Once it crashes, the only way to make it run again - re install the application. Also we see some alert, that asks us to check whether we try to run this application on a proper version of OS X, which doesn't happen on first run. The deployment target of this application 10.6 Can someboby help us to understand what might be the problem? Thanks! Best regards, Nava נשלח מה-iPhone שלי Please excuse typos and shortcuts ___ 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
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 causing my application to crash in the next version of OS X. The private Cocoa framework method name did not have an underscore prefix. So the documentation is correct, “most” but not all private methods in the frameworks have an underscore prefix. There is no way that I would have known about the private Cocoa framework method except examining a class-dump. Apple documentation also states that If you are subclassing a large Cocoa framework class (such as NSView or UIView) and you want to be absolutely sure that your private methods have names different from those in the superclass, you can add your own prefix to your private methods. The prefix should be as unique as possible, perhaps one based on your company or project and of the form XX_. So if your project is called Byte Flogger, the prefix might be BF_addObject: I have never bothered doing this because for one reason BF_addObject looks so ugly as a method name. Does anyone prefix their private method names like Apple recommends when subclassing a large Cocoa framework class? 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? --Richard Charles ___ 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
Re: Private Methods
On 18 Aug 2015, at 15:58, Richard Charles rcharles...@gmail.com 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 subclass replaced a private Cocoa framework method of the same name causing my application to crash in the next version of OS X. The private Cocoa framework method name did not have an underscore prefix. So the documentation is correct, “most” but not all private methods in the frameworks have an underscore prefix. There is no way that I would have known about the private Cocoa framework method except examining a class-dump. Go on, satisfy our curiosity, what did you accidentally override? ___ 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
Re: Private Methods
On 18 Aug 2015, at 16:58, Richard Charles rcharles...@gmail.com 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 maybe even just of getters and setters. OTOH large classes are very likely to have more methods under the hood to implement all the functionality they provide. Cheers, -- Uli Kusterer The Witnesses of TeachtText are everywhere... ___ 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
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 have to make sure my code is
compatible with GNUstep which is the best Cocoa clone for Linux I have
encountered so far - complete with ARC and Blocks but GCD support on GNUstep is
poor (and CoreFoundation support is spotty) so I have to avoid using GCD
completely and use CoreFoundation only sparsely.
On Aug 19, 2015, at 00:18, Simone Tellini cocoa-...@tellini.info wrote:
Il giorno 18/ago/2015, alle ore 18:00, Maxthon Chan m...@maxchan.info 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 is nothing to lock on:
if you used GCD, it would be simpler:
+ (instancetype)sharedInstance
{
static dispatch_once_t once;
static id ret;
dispatch_once( once, ^{
ret = [[self alloc] init];
} );
return ret;
}
--
Simone Tellini
http://tellini.info
___
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/max%40maxchan.info
This email sent to m...@maxchan.info
smime.p7s
Description: S/MIME cryptographic signature
___
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
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 replaced a private Cocoa framework method of the same name causing my application to crash in the next version of OS X. The private Cocoa framework method name did not have an underscore prefix. So the documentation is correct, “most” but not all private methods in the frameworks have an underscore prefix. I'm not even sure most is true. A large number of Apple methods do not start with underscore. I have never bothered doing this because for one reason BF_addObject looks so ugly as a method name. Me neither. I've hit only a few conflicts over the years, in which case I rename. You can set the OBJC_PRINT_REPLACED_METHODS env var to help catch conflicts. Always a good idea with beta version of major OS releases. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
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 included framework and app. One of the two will be used. Which one is undefined. I guess I could simply make sure to only use Parse my private framework, but it seems like this should be fixable somehow... ___ 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
Re: Thread-safe singleton with lazy initialisation
Il giorno 18/ago/2015, alle ore 18:00, Maxthon Chan m...@maxchan.info 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
is nothing to lock on:
if you used GCD, it would be simpler:
+ (instancetype)sharedInstance
{
static dispatch_once_t once;
static id ret;
dispatch_once( once, ^{
ret = [[self alloc] init];
} );
return ret;
}
--
Simone Tellini
http://tellini.info
___
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
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 have to make sure my code is
compatible with GNUstep which is the best Cocoa clone for Linux I have
encountered so far - complete with ARC and Blocks but GCD support on GNUstep is
poor (and CoreFoundation support is spotty) so I have to avoid using GCD
completely and use CoreFoundation only sparsely.
On Aug 19, 2015, at 00:18, Simone Tellini cocoa-...@tellini.info wrote:
Il giorno 18/ago/2015, alle ore 18:00, Maxthon Chan m...@maxchan.info 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 is nothing to lock on:
if you used GCD, it would be simpler:
+ (instancetype)sharedInstance
{
static dispatch_once_t once;
static id ret;
dispatch_once( once, ^{
ret = [[self alloc] init];
} );
return ret;
}
--
Simone Tellini
http://tellini.info
___
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/max%40maxchan.info
This email sent to m...@maxchan.info
smime.p7s
Description: S/MIME cryptographic signature
___
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
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. Also, the C and C++ languages also reserve names that start with underscore and uppercase. See ex: http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier If you're going to use a prefix: don't start with underscore! Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
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 can simplify code completion candidate lists! RC_ _RC_ Three letters gets you farther away from collisions. What can be worse is when the runtime picks one and you don't know which one. And it only occasionally gets the one you don't want. Sent from my iPhone On Aug 18, 2015, at 11:58 PM, Richard Charles rcharles...@gmail.com 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 subclass replaced a private Cocoa framework method of the same name causing my application to crash in the next version of OS X. The private Cocoa framework method name did not have an underscore prefix. So the documentation is correct, “most” but not all private methods in the frameworks have an underscore prefix. There is no way that I would have known about the private Cocoa framework method except examining a class-dump. Apple documentation also states that If you are subclassing a large Cocoa framework class (such as NSView or UIView) and you want to be absolutely sure that your private methods have names different from those in the superclass, you can add your own prefix to your private methods. The prefix should be as unique as possible, perhaps one based on your company or project and of the form XX_. So if your project is called Byte Flogger, the prefix might be BF_addObject: I have never bothered doing this because for one reason BF_addObject looks so ugly as a method name. Does anyone prefix their private method names like Apple recommends when subclassing a large Cocoa framework class? 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? --Richard Charles ___ 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/dangerwillrobinsondanger%40gmail.com This email sent to dangerwillrobinsondan...@gmail.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
Re: Private Methods
On Aug 18, 2015, at 9:01 AM, Mike Abdullah mabdul...@karelia.com 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 large Cocoa framework class (such as NSView or UIView). Perhaps for one reason or another there are cases where framework developers are not able to conveniently prefix a private method name with an underscore so they don’t do it. So I tip my hat to the Apple documentation writers. In this case what they wrote was very accurate. --Richard Charles ___ 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
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:(Class)class;
@end
I believe there will be no chance for private method names clashing any more
unless someone inheriting my class decided to keep using the CGI prefix (which
is stupid in the first place) and keep my private method naming convention.
Or you can refactor your private methods into functions with
CoreFoundation-like argument lists, like this (from source code of Kaleidoscope
Event Engine, class prefix KLS):
void _KLS_RunLoopExecute(void *info) // Use self as
CFRunLoopSourceContext-info and CoreFoundation object memory management
functions otherwise, so I can cast pointers
{
KLSRunLoopSource *self = (__bridge KLSRunLoopSource *)info; // I am working
with CoreFoundation which takes void pointers here. You can get away without
this cast by putting KLSRunLoopSource *self” equivalent directly to the
argument list.
[self execute];
}
On Aug 18, 2015, at 22:58, Richard Charles rcharles...@gmail.com 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 subclass replaced a
private Cocoa framework method of the same name causing my application to
crash in the next version of OS X. The private Cocoa framework method name
did not have an underscore prefix. So the documentation is correct, “most”
but not all private methods in the frameworks have an underscore prefix.
There is no way that I would have known about the private Cocoa framework
method except examining a class-dump.
Apple documentation also states that If you are subclassing a large Cocoa
framework class (such as NSView or UIView) and you want to be absolutely sure
that your private methods have names different from those in the superclass,
you can add your own prefix to your private methods. The prefix should be as
unique as possible, perhaps one based on your company or project and of the
form XX_. So if your project is called Byte Flogger, the prefix might be
BF_addObject:
I have never bothered doing this because for one reason BF_addObject looks so
ugly as a method name.
Does anyone prefix their private method names like Apple recommends when
subclassing a large Cocoa framework class?
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?
--Richard Charles
___
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/max%40maxchan.info
This email sent to m...@maxchan.info
smime.p7s
Description: S/MIME cryptographic signature
___
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
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 cgikitd or an Apache
module mod_objc went up in smoke due to opening up serious security bugs and
lifecycle management issues, I am going back to the path of building the Web
application into an executable, now speaking FastCGI but not launched by the
Web server.
I am modelling the HTTP protocol layer (CGIKit) after ASP.net and the Web layer
(WebUIKit) after UIKit using bits and pieces from Bootstrap+jQuery (which
itself is just a big CSS+JS file) as “controls”. However due to the fact that
FastCGI event loop being part of the protocol some CGIApplication (analogue of
UIApplication) have to be placed in CGIKit. UIKit’s non-atomic-ness is dropped
and all operation have to be atomic, since Web servers are expected to process
multiple requests at the same time.
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 is
nothing to lock on:
#import pthread.h
pthread_mutex_t _CGI_ApplicationStartingMutex;
@implementation CGIApplication
+ (void)initialize
{
pthread_mutex_init(_CGI_ApplicationStartingMutex, NULL);
}
+ (instancetype)sharedApplication
{
if (!CGIApp)
{
pthread_mutex_lock(_CGI_ApplicationStartingMutex);
if (!CGIApp)
{
CGIApp = [[CGIApplication alloc] init];
}
pthread_mutex_unlock(_CGI_ApplicationStartingMutex);
}
return CGIApp;
}
@end
smime.p7s
Description: S/MIME cryptographic signature
___
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
