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

[Quincey Morris]

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” error almost never 
gives any help, but I guess the compiler is reluctant just to admit it has no 
clue.

 On Aug 18, 2015, at 23:04 , Antonio Nunes  wrote:

>if (reminder.exclusions.filter { $0.spansTime(t) }.count > 0) {

It might be clearer to write:

>   if reminder.exclusions.filter ({ $0.spansTime(t) }).count > 0 {




___

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: Swift: 'If' statement needing parentheses on closure return value property access?

[dangerwillrobinsondanger]

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 
executed. 

Honestly it starts to look Perly with that much crammed in either way. 

Sent from my iPhone

> On Aug 19, 2015, at 3:04 PM, Antonio Nunes  wrote:
> 
> 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 error about consecutive statements on a line needing a “;”
> 
> If have to write this:
> 
>if (reminder.exclusions.filter { $0.spansTime(t) }.count > 0) {
>…
>}
> 
> 
> Any ideas why?
> 
> -António
> ___
> 
> 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

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

[Antonio Nunes]

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 error about consecutive statements on a line needing a “;”

If have to write this:

if (reminder.exclusions.filter { $0.spansTime(t) }.count > 0) {
…
}


Any ideas why?

-António
___

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

[Nava ‏Carmon]

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

Re: Private Methods

[Charles Srstka]

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 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: Private Methods

[Quincey Morris]

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 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: Xcode warning from linking to a third-party framework in both app and in framework included in app?

[Steve Mykytyn]

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  wrote:

>
> 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 (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: Private Methods

[Charles Srstka]

> 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 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 

@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

[Quincey Morris]

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 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 
 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

[Charles Srstka]

> 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 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

[Quincey Morris]

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, 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: Private Methods

[Charles Srstka]

> 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 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 
>> 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

[Alex Zavatone]

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 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"

[Seth Willits]

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 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: Private Methods

[Quincey Morris]

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, of 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: Constraints across sibling stack views?

[Seth Willits]

> 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 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: Thread-safe singleton with lazy initialisation

[Greg Parker]

> 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 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

[Charles Srstka]

> 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 which bush the private method is behind. But we can soon 
find out.

MyBaseClass.h in framework:

#import 

@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

[Jens Alfke]

> 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 _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: Thread-safe singleton with lazy initialisation

[Doug Hill]

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 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 > > wrote:
>> 
>> 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 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 
>  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_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

[Maxthon Chan]

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, 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

[Richard Charles]

> 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 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: Private Methods

[Quincey Morris]

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. 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: Xcode warning from linking to a third-party framework in both app and in framework included in app?

[Jens Alfke]

> 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 (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: Private Methods

[Jens Alfke]

> 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’ 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

[Richard Charles]

> 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 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: Thread-safe singleton with lazy initialisation

[Maxthon Chan]

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  wrote:
> 
> 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 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: Thread-safe singleton with lazy initialisation

[Maxthon Chan]

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  wrote:
> 
> 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 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: Thread-safe singleton with lazy initialisation

[Simone Tellini]

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 
> 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

Thread-safe singleton with lazy initialisation

[Maxthon Chan]

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_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

Re: Private Methods

[Sean McBride]

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:



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

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

[Steve Mykytyn]

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 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: Private Methods

[Maxthon Chan]

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  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

Re: Private Methods

[Richard Charles]

> 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 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

[dangerwillrobinsondanger]

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  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

[Sean McBride]

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

Re: Private Methods

[Uli Kusterer]

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 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: Private Methods

[Mike Abdullah]

> 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 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

Private Methods

[Richard Charles]

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: variadic functions missing in bridgesupport file

[Lee Henson]

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  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