RE: NSPathControl

[Lee Ann Rucker]

That's very annoying, because we aren't using it on something that can be 
represented as an URL - it's the currently selected NSTreeController item.

From: cocoa-dev-bounces+lrucker=vmware@lists.apple.com 
[cocoa-dev-bounces+lrucker=vmware@lists.apple.com] on behalf of Jack 
Brindle [jackbrin...@me.com]
Sent: Sunday, May 31, 2015 12:16 PM
To: Cocoa Dev
Subject: Re: NSPathControl

Oops, not any more. clickedPathComponentCell was deprecated in Yosemite.
Instead, look at the URL property. Valid back to 10.5.



> On May 27, 2015, at 3:43 PM, Lee Ann Rucker  wrote:
>
>
> On May 27, 2015, at 2:55 PM, Jens Alfke  wrote:
>
>>
>>> On May 27, 2015, at 2:46 PM, Raglan T. Tiger  
>>> wrote:
>>>
>>> I can setObjectValue: for the path;  now I want to know what path component 
>>> the users selects.  I am using Pop Up style.
>>
>> It’s an NSControl. Wire up the target/action to your IBAction method, either 
>> in IB or programmatically.
>>
>
> And then look at clickedPathComponentCell
>
>
> ___
>
> 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/jackbrindle%40me.com
>
> This email sent to jackbrin...@me.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/lrucker%40vmware.com

This email sent to lruc...@vmware.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: Looking at self = [super init].

[Lee Ann Rucker]

> The "==" case that has been mentioned just omits the second step because self 
> isn't modified by calling [super init]. And the equivalent statements for the 
> other case (! / ==) do the same thing except that the test step is the 
> inverse.

init is allowed to return a different "self", so if you skip the assignment 
you're looking at a stale self.

From: cocoa-dev-bounces+lrucker=vmware@lists.apple.com 
[cocoa-dev-bounces+lrucker=vmware@lists.apple.com] on behalf of Steve 
Christensen [puns...@mac.com]
Sent: Sunday, May 31, 2015 6:45 PM
To: Alex Zavatone
Cc: Cocoa-Dev List
Subject: Re: Looking at self = [super init].

No, it doesn't make a difference. In both cases the compiler will generate a 
"test and branch" to the method's epilogue. For the "=" case:

if (self = [super init]) ...

is equivalent to:

if ((self = [super init]) != nil) ...

is equivalent to:

self = [super init];
if (self) ...

is equivalent to:

self = [super init];
if (self != nil) …

They all:

• Call the superclass' -init method.
• Store the result in self.
• Test if self is not equal to nil/zero.
• Branch to method epilogue (or at least past {...}) if not.

The "==" case that has been mentioned just omits the second step because self 
isn't modified by calling [super init]. And the equivalent statements for the 
other case (! / ==) do the same thing except that the test step is the inverse.

In my opinion having a macro to replace the "self = [super init]" idiom saves 
you a couple of seconds of typing — once; it obfuscates behavior since you need 
to locate the macro to see what it does if you forget; and it is applicable 
only to subclasses where you're calling a superclass' -init method. It doesn't 
help for, e.g., -initWithCoder:, -initWithFrame:, etc., which then means you 
need to come up with a bunch of other macros to handle those cases or you're 
special-casing [super init].

Choosing to do an early return or not is up to you. Personally I prefer the "if 
(self != nil) {...}" case, even if the method is long so that I can see 
structure. To say more risks getting into a "religious" discussion that nobody 
wins. :)


> On May 30, 2015, at 3:20 PM, Alex Zavatone  wrote:
>
> Actually, i was typing by habit and included == instead of = by mistake.
>
> So, while you answered the question, you may have answered the wrong question.
>
> The question is not for
>
> if ( self == [super init])
>
> It's
>
> if ( self =  [super init])
>
> How does that change your answer?
>
> On May 30, 2015, at 6:08 PM, Michael David Crawford wrote:
>
>> While in principle machine code implementations of subroutines can
>> return from several different places, in practice they don't.  Rather
>> the compiler's code generator emits a branch instruction to the end of
>> the subroutine, there there is an "epilog".
>>
>> There are many good reasons for returning from the middle in certain
>> specific cases; what if the only epilog you need is an "rts"?
>> Branching to the epilog could cause a cache miss.
>>
>> I expect the compiler developers know all about this but don't
>> typically avail themselves of it because writing compilers is
>> difficult.
>>
>> To be clear, the following source code:
>>
>> - (id) init
>> {
>>  if ( self == [super init] ) return nil;
>>
>>  // lots of code goes here
>>
>>  return self;
>> }
>>
>> ... is implemented as something like this, but in machine code:
>>
>> - (id) init
>> {
>>  id result;
>>  if ( self == [super init] ){
>>result = nil;
>>goto epilog;
>>  }
>>
>>  // lots of code goes here
>>  result = self;
>>
>> epilog:
>>  return result;
>> }
>> Michael David Crawford, Consulting Software Engineer
>> mdcrawf...@gmail.com
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.warplife.com_mdc_&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=ie7S-J__EKnfyVOBV7-jV2rZ--p47O6vkyTklpDM3h4&m=Z8vcdjmsMKlbvM2wCAfNohcqAEcoUBSmr2LdV39oZp8&s=0LcsucVzgw_rFosbryao4sTH3L4wj7OecTlM6LeQ3gU&e=
>>
>>  Available for Software Development in the Portland, Oregon Metropolitan
>> Area.
>>
>>
>> On Fri, May 29, 2015 at 6:25 PM, Graham Cox  wrote:
>>>
 On 30 May 2015, at 3:22 am, Alex Zavatone  wrote:

 // We don't care if this gets long.
>>>
>>>
>>> My take is that you're rewriting a well-recognised idiom to solve a 
>>> non-existent problem.
>>>
>>> The well-recognised idiom makes it easy to verify it's correct. Hiding a 
>>> different construct inside a macro obscures that, making it harder to 
>>> verify the code. It's not "wrong" exactly, just harder to see at a glance 
>>> that it's right.
>>>
>>> The non-existent problem you're trying to solve is that the gap between a 
>>> pair of braces could get large. So what? Early returns can be another 
>>> source of bugs, so structural purists would tell you that you shouldn't do 
>>> that. Sometimes I think it's justified, but not usually worthwhile. Another 
>>>

Re: Looking at self = [super init].

[Dave]

> in some cases, the set up within the parens could get pretty long.  In cases 
> like that, I generally set up another method to handle that for organization, 
> but if you're passing objects into into your init method, then you're passing 
> more data again and the code could get less cleaner looking than it could be.
> 
> So, I thought, "why don't we check if self != [super init] and then 
> immediately return if that is the case?”

Totally agree, I always do it like this:

-(instanceType) init
{
self = [super init];
if (self == nil)
return nil;

// Init code here

return self;
}

I nearly prefer a fast return over using a Brace, for instance:

-(BOOL) someMethodWithParameter1:(NSString*) theParam1 andParam2:(NSString*) 
theParam2
{
if (theParam1 == nil)
return NO;

if (theParam2 == nil)
return NO;

// Other code here


return YES;
}

In preference to:

-(BOOL) someMethodWithParameter1:(NSString*) theParam1 andParam2:(NSString*) 
theParam2
{if (theParam1 != nil)
{
if (theParam2 != nil)
{
// Other code here
}

return YES;
}   

return NO;
}

All the Best
Dave




___

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: [PSA] OSStatus.com -- Error code lookup

[Uli Kusterer]

On 31 May 2015, at 20:12, Ben Kennedy  wrote:
> Pardon my thickness, but what is the purpose of the "utf8" parameter anyway? 
> Removing it from the query string appears to have no material impact on the 
> results:
> 
> http://www.osstatus.com/search/results?search=-43 
> 

It's a trick web devs use to get certain browsers to switch on UTF8 support, 
IIRC.
___

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: [PSA] OSStatus.com -- Error code lookup

[Ben Kennedy]

On 01 Jun 2015, at 5:59 am, Uli Kusterer  wrote:

> It's a trick web devs use to get certain browsers to switch on UTF8 support, 
> IIRC.

Isn't that what Accept: and Content-Type: headers are for?

Oh... apparently seems like a cheap workaround for broken MSIE:

http://programmers.stackexchange.com/questions/168751/is-the-use-of-utf8-✓-preferable-to-utf8-true

Still seems inadvisable to me.

b


___

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

Concatenating two NSIndexPath objects

[Dave]

Hi All,

I’ve got an Index Path, that needs to have an extra level added to it at the 
beginning.

e.g.

0.1.2.3.4

Needs to be:

0.0.1.2.3.4

Is there are easy way to do this that doesn’t involve playing with NSUInteger 
Arrays?

If not I think I’ll write a category method that does it, any tips greatly 
appreciated.

All the Best
Dave


___

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: Looking at self = [super init].

[Dave]

> On 30 May 2015, at 02:25, Graham Cox  wrote:
> 
> 
>> On 30 May 2015, at 3:22 am, Alex Zavatone  wrote:
>> 
>> // We don't care if this gets long.
> 
> 
> My take is that you’re rewriting a well-recognised idiom to solve a 
> non-existent problem.

The problem is that it makes the init method less readable and more error prone.

> The well-recognised idiom makes it easy to verify it’s correct. Hiding a 
> different construct inside a macro obscures that, making it harder to verify 
> the code. It’s not “wrong” exactly, just harder to see at a glance that it’s 
> right.
> 
> The non-existent problem you’re trying to solve is that the gap between a 
> pair of braces could get large. So what? Early returns can be another source 
> of bugs, so structural purists would tell you that you shouldn’t do that.

So can extra braces along with just about everything else you write!
> 
> Source code is for humans, so it should be as readable as you can possibly 
> make it. Macros often hinder that. Unaligned braces hinder that. Multiple 
> statements per line hinder that.

Exactly, so make it more readable, to me anyway, unnecessary braces just add to 
complexity or at least makes the method look more complex than it actually is. 

Cheers
Dave



___

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

[Lee Ann Rucker]

Whew. It’s not showing up in the docs yet, but in the header there’s

/* The clicked NSPathControlItem, or nil, if no item has been clicked. The 
clickedPathItem is generally only valid while the action or doubleAction is 
being sent.
 */
@property (readonly) NSPathControlItem *clickedPathItem NS_AVAILABLE_MAC(10_10);

/* The array of NSPathControlItems currently being displayed.
Each item must be an NSPathControlItem.  Do not subclass NSPathControlItem. 
You cannot set this value to nil, but should instead set it to an empty array.
 */
@property (copy) NSArray *pathItems NS_AVAILABLE_MAC(10_10);

Because I couldn’t possibly be the only person using that for a non-URL path. 
Even if I could URL-ify my data, I still need to tweak the icons to match it.

On Jun 1, 2015, at 12:28 AM, Lee Ann Rucker 
mailto:lruc...@vmware.com>> wrote:

That's very annoying, because we aren't using it on something that can be 
represented as an URL - it's the currently selected NSTreeController item.

From: 
cocoa-dev-bounces+lrucker=vmware@lists.apple.com
 
[cocoa-dev-bounces+lrucker=vmware@lists.apple.com]
 on behalf of Jack Brindle [jackbrin...@me.com]
Sent: Sunday, May 31, 2015 12:16 PM
To: Cocoa Dev
Subject: Re: NSPathControl

Oops, not any more. clickedPathComponentCell was deprecated in Yosemite.
Instead, look at the URL property. Valid back to 10.5.



On May 27, 2015, at 3:43 PM, Lee Ann Rucker 
mailto:lruc...@vmware.com>> wrote:


On May 27, 2015, at 2:55 PM, Jens Alfke 
mailto:j...@mooseyard.com>> wrote:


On May 27, 2015, at 2:46 PM, Raglan T. Tiger 
mailto:r...@crusaderrabbit.net>> wrote:

I can setObjectValue: for the path;  now I want to know what path component the 
users selects.  I am using Pop Up style.

It’s an NSControl. Wire up the target/action to your IBAction method, either in 
IB or programmatically.


And then look at clickedPathComponentCell


___

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/jackbrindle%40me.com

This email sent to jackbrin...@me.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/lrucker%40vmware.com

This email sent to lruc...@vmware.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/lrucker%40vmware.com

This email sent to lruc...@vmware.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: NSPathControl

[Quincey Morris]

On Jun 1, 2015, at 13:59 , Lee Ann Rucker  wrote:
> 
> Because I couldn’t possibly be the only person using that …

What does that dangling “because” refer to? I can’t make it out.

>  for a non-URL path.

What’s a non-URL path? AFAIK a URL** always contains a path, even if only 
relative, and even if surrounded by other stuff.

> Even if I could URL-ify my data, …

If you look at the header file for NSPathControlItem, it has a URL property 
that appears to URL-ify the path in spite of your data.

> I still need to tweak the icons to match it.

There are actually 3 cases, I think:

1. The control’s URL is not a file URL.

2. The control’s URL is a file URL for a file that exists.

3. The control’s URL is a file URL for a file that doesn’t exist.

Doesn’t NSPathControl do some special things in case #3, for things like the 
user’s home folder etc? Does this mess you up in cases where your fake path 
happens to match the real path to an actual file?

Sorry if I sound nit-picky here. That’s not my intention. I’m actually 
interested in your success at using NSPathControl for an arbitrary 
non-file-system path, since I came to the conclusion a couple of years ago that 
it was too unreliable an approach. I’m wondering if it’s now/again a valid use 
case.


** And I mean “URL”, not “NSURL”, though I guess the same thing applies to 
NSURL as a consequence.

___

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

[Quincey Morris]

On Jun 1, 2015, at 14:39 , Quincey Morris  
wrote:
> 
> Doesn’t NSPathControl do some special things in case #3

Oops, I meant case #2.



___

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: Concatenating two NSIndexPath objects

[Jonathan Hull]

I found this in a category in a (very) old project of mine.  You could easily 
speed it up by using arrays, but this version worked well enough for my needs.

- (NSIndexPath*) indexPathByAddingIndexPath:(NSIndexPath*) indexPath {
NSIndexPath* path = [self copy];
for (NSUInteger i = 0; i < indexPath.length ; i++) {
path = [path indexPathByAddingIndex:[indexPath indexAtPosition:i]];
}
return path;
}

- (NSIndexPath *)indexPathByAddingIndexInFront:(NSUInteger)index {
NSIndexPath* indexPath = [NSIndexPath indexPathWithIndex:index];
return [indexPath indexPathByAddingIndexPath:self];
}

Thanks,
Jon

> On Jun 1, 2015, at 11:06 AM, Dave  wrote:
> 
> Hi All,
> 
> I’ve got an Index Path, that needs to have an extra level added to it at the 
> beginning.
> 
> e.g.
> 
> 0.1.2.3.4
> 
> Needs to be:
> 
> 0.0.1.2.3.4
> 
> Is there are easy way to do this that doesn’t involve playing with NSUInteger 
> Arrays?
> 
> If not I think I’ll write a category method that does it, any tips greatly 
> appreciated.
> 
> All the Best
> Dave
> 
> 
> ___
> 
> 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/jhull%40gbis.com
> 
> This email sent to jh...@gbis.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: Looking at self = [super init].

[Britt Durbrow]

My take on it is that this is somewhat a style issue; and as such is 
quasi-religious in nature; with adherents on all sides of the issue with valid 
points to make.

But FWIW, my, er, “sect” (to take a metaphor slightly beyond the breaking 
point) adheres to something that looks like this (er, coded in Mail.app - take 
with appropriate grains of salt):

#define RSHOddBall_randomDictionaryCapacity (100)

@implementation RSHOddBall

-(instancetype)init
{
if(!(self=[super init])) return nil;

someIvar=12345;
someRandomDictionary=[NSMutableDictionary 
initWithCapacity:RSHOddBall_randomDictionaryCapacity];

return self;
};


Notes:

I code with the full capabilities of modern IDEs in mind; for example, I don’t 
worry about setting off macros in all caps as syntax highlighting takes care 
that; and if I see a macro that I don’t immediately know exactly what it does, 
well it’s definition is only a command-click away.

I do believe that for readability, braces should be lined up vertically. Yes, 
it makes the source code longer - but ‘comeon, we’ve got *very* high resolution 
monitors these days, we can fit a *lot* of text on them!

I happen to like an extra semicolon after a closing brace when it’s the end of 
the logical block. It’s just the way I like it to look (it feels ‘funny’ to me 
to have a statement end without one); the compiler ignores it. YMMV.

Within a class I’ll often use direct ivar access; but outside of it I’ll almost 
always use accessors (there are some oddball performance related exceptions to 
this, but they are always heavily documented on the variable declarations, and 
used in a tightly integrated class-cluster like situation, hence the *almost* 
always - but it’s the exception, definitely not the rule). Yes, I know that 
there are valid reasons to use accessors within the class, but for most of my 
code it’s not warranted. Transforming direct ivar access to use accessors is a 
simple regex search and replacement should I need to refactor it. Again, YMMV.

I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary -- 
it doesn’t help with namespacing (if a subclass and a superclass both declare 
_someVariable with the underscore they will collide just as badly as if they 
declare someVariable without one) and ivars vs accessors are obvious by 
context: [self obviouslyAnAccessor] or self.obviouslyAnAccessor vs 
obviouslyAnIvar (or very rarely, someObject->obviouslyAnIvar). I do, however, 
use them for doing pseudo-namespacing at levels below the project prefix (as 
evidenced by RSHOddBall_randomDictionaryCapacity).

I personally find early returns to be very useful, and also make use of 
forward-jumping goto statements sometimes (i.e, goto bail;).


However, when working on somebody else’s code (like, say, an open-source 
library); I’ll adopt their coding style, even if some of the things they do 
make my eyes itch. ;-)
___

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: Looking at self = [super init].

[Charles Srstka]

On Jun 1, 2015, at 4:52 PM, Britt Durbrow 
 wrote:
> 
> I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary 
> -- it doesn’t help with namespacing (if a subclass and a superclass both 
> declare _someVariable with the underscore they will collide just as badly as 
> if they declare someVariable without one)

Which is not at all, actually:

#import 

@interface Foo : NSObject

- (void)fooLogAnIvar;

@end

@interface Bar : Foo

- (void)barLogAnIvar;

@end

int main(int argc, const char * argv[]) {
@autoreleasepool {
Bar *bar = [Bar new];

[bar fooLogAnIvar];
[bar barLogAnIvar];
}
return 0;
}

@implementation Foo {
NSString *_anIvar;
}

- (instancetype)init {
self = [super init];

if (self == nil) {
return nil;
}

_anIvar = @"Foo";

return self;
}

- (void)fooLogAnIvar {
NSLog(@"Foo: _anIvar is %@", _anIvar);
}

@end

@implementation Bar {
NSString *_anIvar;
}

- (instancetype)init {
self = [super init];

if (self == nil) {
return nil;
}

_anIvar = @"Bar";

return self;
}

- (void)barLogAnIvar {
NSLog(@"Bar: _anIvar is %@", _anIvar);
}

@end

2015-06-01 17:12:16.328 test[17203:2499855] Foo: _anIvar is Foo
2015-06-01 17:12:16.329 test[17203:2499855] Bar: _anIvar is Bar

> and ivars vs accessors are obvious by context: [self obviouslyAnAccessor] or 
> self.obviouslyAnAccessor vs obviouslyAnIvar (or very rarely, 
> someObject->obviouslyAnIvar).


Non-underscored ivars vs. local variables, however, are not obvious at all, 
especially if the method is large.

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: Looking at self = [super init].

[Michael David Crawford]

I've always used "m" to prefix ivars: mSpeed, mDistance.  I use "s"
for statics and "k" for constants.

I'd like to find a good convention for distinguishing properties but
haven't really found one that is appealing to me.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Mon, Jun 1, 2015 at 3:14 PM, Charles Srstka  wrote:
> On Jun 1, 2015, at 4:52 PM, Britt Durbrow 
>  wrote:
>>
>> I don't use underscores to prefix ivars. I think it's ugly, and unnecessary 
>> -- it doesn't help with namespacing (if a subclass and a superclass both 
>> declare _someVariable with the underscore they will collide just as badly as 
>> if they declare someVariable without one)
>
> Which is not at all, actually:
>
> #import 
>
> @interface Foo : NSObject
>
> - (void)fooLogAnIvar;
>
> @end
>
> @interface Bar : Foo
>
> - (void)barLogAnIvar;
>
> @end
>
> int main(int argc, const char * argv[]) {
> @autoreleasepool {
> Bar *bar = [Bar new];
>
> [bar fooLogAnIvar];
> [bar barLogAnIvar];
> }
> return 0;
> }
>
> @implementation Foo {
> NSString *_anIvar;
> }
>
> - (instancetype)init {
> self = [super init];
>
> if (self == nil) {
> return nil;
> }
>
> _anIvar = @"Foo";
>
> return self;
> }
>
> - (void)fooLogAnIvar {
> NSLog(@"Foo: _anIvar is %@", _anIvar);
> }
>
> @end
>
> @implementation Bar {
> NSString *_anIvar;
> }
>
> - (instancetype)init {
> self = [super init];
>
> if (self == nil) {
> return nil;
> }
>
> _anIvar = @"Bar";
>
> return self;
> }
>
> - (void)barLogAnIvar {
> NSLog(@"Bar: _anIvar is %@", _anIvar);
> }
>
> @end
>
> 2015-06-01 17:12:16.328 test[17203:2499855] Foo: _anIvar is Foo
> 2015-06-01 17:12:16.329 test[17203:2499855] Bar: _anIvar is Bar
>
>> and ivars vs accessors are obvious by context: [self obviouslyAnAccessor] or 
>> self.obviouslyAnAccessor vs obviouslyAnIvar (or very rarely, 
>> someObject->obviouslyAnIvar).
>
>
> Non-underscored ivars vs. local variables, however, are not obvious at all, 
> especially if the method is large.
>
> 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/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@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: Looking at self = [super init].

[pscott]

On 6/1/2015 2:52 PM, Britt Durbrow wrote:

I personally find early returns to be very useful, and also make use of 
forward-jumping goto statements sometimes (i.e, goto bail;).


FWIW, while I embrace both early returns and the goto statement where it 
makes sense, for the case you make, I would use a break statement inside 
a do block:


#define end_do while (0)

do {
if ( bailCondition ) break;
if ( someOtherBailCondition ) break;
   ...
} end_do;

This creates another level of indentation, but structurally, that's the 
point.



However, when working on somebody else’s code (like, say, an open-source 
library); I’ll adopt their coding style, even if some of the things they do 
make my eyes itch. ;-)


We are cut from the same cloth, there.

Paul

--
Paul Scott
psc...@skycoast.us




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: Looking at self = [super init].

[Michael David Crawford]

The paper entitled "Goto Considered Harmful" - by Dijkstra? - was
criticizing spaghetti code.  At the time, commonly used programming
languages did not have control flow statements like "if/then/else",
"do/while", "while" or "switch/case".  Instead, other than fortran's
"do/continue" you had to roll your own control flow; often it was done
quite poorly.

If you're experienced with coding as well as careful about it, there's
no real good reason that one cannot use goto to create control flow
that's not built-in to the language.  Despite that it is commonly
asserted that if you use goto, then you are clueless.  That's just
wrong.

Assembly code doesn't really have control flow constructs.  You make
them out of gotos - condition or unconditional branches.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Mon, Jun 1, 2015 at 4:05 PM, pscott  wrote:
> On 6/1/2015 2:52 PM, Britt Durbrow wrote:
>>
>> I personally find early returns to be very useful, and also make use of
>> forward-jumping goto statements sometimes (i.e, goto bail;).
>
>
> FWIW, while I embrace both early returns and the goto statement where it
> makes sense, for the case you make, I would use a break statement inside a
> do block:
>
> #define end_do while (0)
>
> do {
> if ( bailCondition ) break;
> if ( someOtherBailCondition ) break;
>...
> } end_do;
>
> This creates another level of indentation, but structurally, that's the
> point.
>
>> However, when working on somebody else's code (like, say, an open-source
>> library); I'll adopt their coding style, even if some of the things they do
>> make my eyes itch. ;-)
>
>
> We are cut from the same cloth, there.
>
> Paul
>
> --
> Paul Scott
> psc...@skycoast.us
>
>
>
> ___
>
> 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/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@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: Looking at self = [super init].

[Steve Mills]

> On Jun 1, 2015, at 18:16, Michael David Crawford  wrote:
> 
> Assembly code doesn't really have control flow constructs.  You make
> them out of gotos - condition or unconditional branches.

But assembly doesn't have to worry about dtors and such. That's probably the 
biggest reason to avoid goto. Even if your code would be clean with a goto now 
doesn't mean that some engineer in the future won't come along and add some 
variable that needs its dtor, but is unaware of the evilness that lurks within.

Steve via iPad


___

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

[Lee Ann Rucker]

On Jun 1, 2015, at 2:39 PM, Quincey Morris 
mailto:quinceymor...@rivergatesoftware.com>>
 wrote:

On Jun 1, 2015, at 13:59 , Lee Ann Rucker 
mailto:lruc...@vmware.com>> wrote:

Because I couldn’t possibly be the only person using that …

What does that dangling “because” refer to? I can’t make it out.

My previous comment where I said I was using it to show the “path” to the 
current NSTreeController selection. I create my own NSPathComponentCells by 
finding each treeNode between the root and the selection. The cell's 
representedObject is the NSTreeNode for that part of the “path” & the 
title/image comes from the [treeNode representedObject], and the IBAction uses 
[clickedPathComponentCell representedObject] to find it.

   NSIndexPath *iterationPath = [[self.treeController selectionIndexPaths] 
firstObject];
   NSMutableArray *pathComponentArray = [NSMutableArray array];
   NSTreeNode *topNode = [self.treeController arrangedObjects];

   while ([iterationPath length] > 0) {
  NSTreeNode *treeNode = [topNode descendantNodeAtIndexPath:iterationPath];
  [pathComponentArray insertObject:[self componentCellFromNode:treeNode]
   atIndex:0];
  iterationPath = [iterationPath indexPathByRemovingLastIndex];
   }
   [pathControl setPathComponentCells:pathComponentArray];

___

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: Looking at self = [super init].

[Quincey Morris]

On Jun 1, 2015, at 14:52 , Britt Durbrow 
 wrote:
> 
> I happen to like an extra semicolon after a closing brace when it’s the end 
> of the logical block. It’s just the way I like it to look (it feels ‘funny’ 
> to me to have a statement end without one); the compiler ignores it. YMMV.

The issue here is that you may find it comforting to see ‘;’ at the “end” of a 
statement, but it skates right over the ambiguity of when a “{ … }” construct 
is to be regard as a “logical block”. The compiler does *not* ignore the “;” 
after “}”. The following does *not* compile:

if (…) {…}; else {…};

You can argue that the intermediate ‘;’ not the end of a logical block, but if 
a “}” isn’t the end of a logical block, you’ve just changed a stylistic rule 
into a syntax rule.

> I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary 
> -- it doesn’t help with namespacing (if a subclass and a superclass both 
> declare _someVariable with the underscore they will collide just as badly as 
> if they declare someVariable without one)

The real reason for this convention is something else. In the bad old days 
(meaning, more or less, pre-Leopard), there were multiple conflicting 
conventions about using “_” for naming. Perhaps it was when the clang compiler 
was introduced, I can’t remember exactly, but Apple decreed the current 
convention, to work around the inherent unsafety of Obj-C namespacing:

— Private 3rd party instance variables *should* use the underscore.

— Private 3rd party methods *must not* use the underscore.

It’s not really a question of good or bad. It’s more a question of what we were 
required to do to avoid future Cocoa frameworks releases from retroactively 
breaking our apps.

On Jun 1, 2015, at 15:14 , Charles Srstka  wrote:
> 
> Which is not at all, actually:

The answer is “not at all” only with the modern ABI. 32-bit Mac compilations 
will conflict.



___

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: Looking at self = [super init].

[Michael David Crawford]

Steve - are you saying that C++ destructors aren't called if you use a goto?

It was my understanding that the destructor is called if you go out of
scope for any reason, even if it's a goto.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Mon, Jun 1, 2015 at 4:39 PM, Quincey Morris
 wrote:
> On Jun 1, 2015, at 14:52 , Britt Durbrow 
>  wrote:
>>
>> I happen to like an extra semicolon after a closing brace when it's the end 
>> of the logical block. It's just the way I like it to look (it feels 'funny' 
>> to me to have a statement end without one); the compiler ignores it. YMMV.
>
> The issue here is that you may find it comforting to see ';' at the "end" of 
> a statement, but it skates right over the ambiguity of when a "{ ... }" 
> construct is to be regard as a "logical block". The compiler does *not* 
> ignore the ";" after "}". The following does *not* compile:
>
> if (...) {...}; else {...};
>
> You can argue that the intermediate ';' not the end of a logical block, but 
> if a "}" isn't the end of a logical block, you've just changed a stylistic 
> rule into a syntax rule.
>
>> I don't use underscores to prefix ivars. I think it's ugly, and unnecessary 
>> -- it doesn't help with namespacing (if a subclass and a superclass both 
>> declare _someVariable with the underscore they will collide just as badly as 
>> if they declare someVariable without one)
>
> The real reason for this convention is something else. In the bad old days 
> (meaning, more or less, pre-Leopard), there were multiple conflicting 
> conventions about using "_" for naming. Perhaps it was when the clang 
> compiler was introduced, I can't remember exactly, but Apple decreed the 
> current convention, to work around the inherent unsafety of Obj-C namespacing:
>
> -- Private 3rd party instance variables *should* use the underscore.
>
> -- Private 3rd party methods *must not* use the underscore.
>
> It's not really a question of good or bad. It's more a question of what we 
> were required to do to avoid future Cocoa frameworks releases from 
> retroactively breaking our apps.
>
> On Jun 1, 2015, at 15:14 , Charles Srstka  wrote:
>>
>> Which is not at all, actually:
>
> The answer is "not at all" only with the modern ABI. 32-bit Mac compilations 
> will conflict.
>
>
>
> ___
>
> 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/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@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: Looking at self = [super init].

[Marco S Hyman]

On Jun 1, 2015, at 4:16 PM, Michael David Crawford  wrote:
> 
> The paper entitled "Goto Considered Harmful" - by Dijkstra? - was
> criticizing spaghetti code.  At the time, commonly used programming
> languages did not have control flow statements like "if/then/else",
> "do/while", "while" or "switch/case".  Instead, other than fortran's
> "do/continue" you had to roll your own control flow; often it was done
> quite poorly.

Minor nit... Dijkstra was one of the authors of Algol 60 which had plenty
of control flow statements.  He explicitly mentions goto with respect to
algol in his “considered harmful” note:

   "Finally I should like to record (as I remember it quite distinctly) how
Heinz Zemanek at the pre-ALGOL meeting in early 1959 in Copenhagen quite
explicitly expressed his doubts whether the go to statement should be
treated on equal syntactic footing with the assignment statement. To a
modest extent I blame myself for not having then drawn the consequences
of his remark.”

However, he follows that with this:

   "I remember having read the explicit recommendation to restrict the use of
the go to statement to alarm exits, but I have not been able to trace it;
presumably, it has been made by C. A. R. Hoare.”

which sounds like the “religion” being discussed.   My feelings on that topic
are private, as I feel most religious beliefs should be :)

Marc
___

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: Looking at self = [super init].

[Steve Mills]

> On Jun 1, 2015, at 19:01, Michael David Crawford  wrote:
> 
> Steve - are you saying that C++ destructors aren't called if you use a goto?
> 
> It was my understanding that the destructor is called if you go out of
> scope for any reason, even if it's a goto.

Hmm, either I'm thinking of something else, or I just can't find the right 
docs. I just learned to never ever use them, and my life as a developer is just 
dandy. :)

Steve via iPad


___

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

[Graham Cox]

> On 2 Jun 2015, at 7:39 am, Quincey Morris 
>  wrote:
> 
> What’s a non-URL path? AFAIK a URL** always contains a path, even if only 
> relative, and even if surrounded by other stuff.

> If you look at the header file for NSPathControlItem, it has a URL property 
> that appears to URL-ify the path in spite of your data.
> 
>> I still need to tweak the icons to match it.
> 
> There are actually 3 cases, I think:
> 
> 1. The control’s URL is not a file URL.
> 
> 2. The control’s URL is a file URL for a file that exists.
> 
> 3. The control’s URL is a file URL for a file that doesn’t exist.
> 


4. The control represents a “path” that isn’t anything like a URL, such as a 
tree node (e.g. a NSIndexPath or something equivalent).

Like Lee Ann, I use a NSPathControl for this. Forcing the data it represents to 
be a URL is making it a lot more limited than its original design.

—Graham



___

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: Looking at self = [super init].

[Graham Cox]

> On 2 Jun 2015, at 10:15 am, Steve Mills  wrote:
> 
>> It was my understanding that the destructor is called if you go out of
>> scope for any reason, even if it's a goto.
> 
> Hmm, either I'm thinking of something else, or I just can't find the right 
> docs.


I think Michael is correct a dtor is called no matter how the scope that it 
belongs to is exited.

But that doesn’t apply to us as Obj-C developers (not sure if Swift has the 
concept) as we can’t have stack-based objects.


But anyway, the argument is really about readability and not introducing bugs. 
If you have a complex method whose function can’t be determined at a glance 
(and that in itself could be a good argument for a refactoring) with multiple 
exit points rather than one clear exit point at the end, it can often be hard 
to follow the flow of control. If the function is later changed to return a 
different type (BOOL becomes int for example) then making sure all your exit 
points return the right thing is extra work. That said, early returns up front 
for bad parameters or obvious sanity check failures are likely to be more 
readable. Overall, the judgement isn’t a rule, it’s about the craft and style 
of programming.

Excessive indentation is bad, but probably on balance to be preferred (IMHO) to 
multiple exit points. Yes, the compiler turns all of those into a goto anyway 
(or at least a branch to the final RTS or whatever, it rarely inserts an RTS in 
the middle), but that’s completely hidden from us as it should be.

Maybe this is just down to one’s personal history. If that’s ever included 
extensive Pascal (as mine does) then early returns and gotos are almost 
anathema. If you cut your teeth on C-like languages, probably less so.

—Graham



___

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: Looking at self = [super init].

[pscott]

On 6/1/2015 5:05 PM, Marco S Hyman wrote:
... My feelings on that topic are private, as I feel most religious 
beliefs should be :)
It can be shown in a secular way that there are edge cases where a goto 
in the C language is appropriate, in no small part because C lacks 
labelled break and continue statements. Avoiding goto in those edge 
cases would unnecessarily compromise code readability and efficiency. 
But because there are religious zealots who would disagree with secular 
arguments, I will say no more on the subject.


--
Paul Scott
psc...@skycoast.us




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: Looking at self = [super init].

[Charles Srstka]

On Jun 1, 2015, at 6:39 PM, Quincey Morris 
 wrote:
> 
> On Jun 1, 2015, at 15:14 , Charles Srstka  > wrote:
>> 
>> Which is not at all, actually:
> 
> The answer is “not at all” only with the modern ABI. 32-bit Mac compilations 
> will conflict.

That’s true. Also, code written for the Mac Plus using THINK C 3.0 will 
conflict. However, compilation targets that people are actually still using in 
2015 will not conflict.

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: Looking at self = [super init].

[Michael David Crawford]

I quite commonly fix bugs by refactoring all the lengthy routines into
several shorter ones.

I'll do that especially when I can't determine the cause of a bug;
instead I'll just look around for messy source then tidy it up.  That
has a way of making bugs go away.

On 6/1/15, Charles Srstka  wrote:
> On Jun 1, 2015, at 6:39 PM, Quincey Morris
>  wrote:
>>
>> On Jun 1, 2015, at 15:14 , Charles Srstka > > wrote:
>>>
>>> Which is not at all, actually:
>>
>> The answer is "not at all" only with the modern ABI. 32-bit Mac
>> compilations will conflict.
>
> That's true. Also, code written for the Mac Plus using THINK C 3.0 will
> conflict. However, compilation targets that people are actually still using
> in 2015 will not conflict.
>
> 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/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@gmail.com


-- 
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.
___

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

[Quincey Morris]

On Jun 1, 2015, at 17:56 , Graham Cox  wrote:
> 
> 4. The control represents a “path” that isn’t anything like a URL, such as a 
> tree node

My point was that NSPathControl apparently constructs URLs out of the path 
components, regardless of what you’re really representing, and regardless of 
how you originally configured them. From NSPathControl.h:

> /* Gets and sets the path value displayed. When setting, an array of 
> NSPathControlItems will automatically be set based on the path in the 'url'. 
> If the 'url' is a file URL (returns YES from isFileURL), the images will 
> automatically be filled up with file icons, if the path exists.  The URL 
> value itself is stored in the objectValue of the control.
>  */
> @property (copy) NSURL *URL;

Note where it says “is stored in the objectValue”. Similarly, in 
NSPathControlItem.h:

> /* A url for the partial path from the beginning up to this particular item.
>  */
> @property (readonly) NSURL *URL;

None of this is a problem, since you should be able to construct a URL out of 
any array of component strings, with proper escaping. So regardless of your 
intention, NSPathControl may attempt to classify this URL as one of #1-#3. Your 
case #4 still produces a URL that is one of those 3 cases.

I was really asking whether NSPathControl can mess up what you and Lee Ann are 
doing, if you give it an array of components whose titles happen to be 
[“Users”, “yourname”], for example. In that case, the URL 
file:///Users/yourname  really exists — it’s your home 
directory — and I’m not sure that NSPathControl won’t display this is starting 
with your home directory icon, and dropping the first component. At least, 
that’s what I think I’ve seen it do with that URL. Presumably this will not be 
what you intended, if it happens.

But it’s not that important. If it seems to be working for you, I’m happy to 
hear it.



___

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: Looking at self = [super init].

[Britt Durbrow]

In no particular order:

> On Jun 1, 2015, at 7:27 PM, Michael David Crawford  
> wrote:
> 
> I quite commonly fix bugs by refactoring all the lengthy routines into
> several shorter ones.
> 


I have the same rule of thumb - if it’s not obvious what’s going on, I should 
probably think about refactoring it into smaller chunks.

—

> 
> 
> On Jun 1, 2015, at 6:09 PM, Graham Cox  wrote:
> 
> If you have a complex method whose function can’t be determined at a glance 
> (and that in itself could be a good argument for a refactoring) with multiple 
> exit points rather than one clear exit point at the end, it can often be hard 
> to follow the flow of control.

Um… don’t do that? :-)

Yes, early returns & gotos are power tools that can be misused. YMMV, wear 
proper personal protective equipment, void where prohibited and/or 
uninitialized, not for sale to miners, etc...

…and no, I have no idea why people who dig ore out of the ground shouldn’t be 
allowed to buy it (I suppose that’s what I get for asking a muppet for legal 
advice, eh? :-) 

—


> 
> On Jun 1, 2015, at 4:39 PM, Quincey Morris 
>  wrote:
> 
> On Jun 1, 2015, at 14:52 , Britt Durbrow 
>  wrote:
>> 
>> I happen to like an extra semicolon after a closing brace when it’s the end 
>> of the logical block. It’s just the way I like it to look (it feels ‘funny’ 
>> to me to have a statement end without one); the compiler ignores it. YMMV.
> 
> The issue here is that you may find it comforting to see ‘;’ at the “end” of 
> a statement, but it skates right over the ambiguity of when a “{ … }” 
> construct is to be regard as a “logical block”. The compiler does *not* 
> ignore the “;” after “}”. The following does *not* compile:
> 
>   if (…) {…}; else {…};
> 
> You can argue that the intermediate ‘;’ not the end of a logical block, but 
> if a “}” isn’t the end of a logical block, you’ve just changed a stylistic 
> rule into a syntax rule.
> 

The entire if statement is what I consider a logical block: the else {...} does 
not, and indeed cannot, stand alone.

if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
};

[anotherObject doesSomethingElseEntirely];

is the same to the compiler as:

if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
}

[anotherObject doesSomethingElseEntirely];

or even:

someCondition?[someObject doSomething]:[someObject 
doSomeOtherThing],[anotherObject doesSomethingElseEntirely];

although I will say that the readability on the third example does suffer 
somewhat. :-)

—

>> I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary 
>> -- it doesn’t help with namespacing (if a subclass and a superclass both 
>> declare _someVariable with the underscore they will collide just as badly as 
>> if they declare someVariable without one)
> 
> The real reason for this convention is something else. In the bad old days 
> (meaning, more or less, pre-Leopard), there were multiple conflicting 
> conventions about using “_” for naming. Perhaps it was when the clang 
> compiler was introduced, I can’t remember exactly, but Apple decreed the 
> current convention, to work around the inherent unsafety of Obj-C namespacing:
> 
> — Private 3rd party instance variables *should* use the underscore.
> 
> — Private 3rd party methods *must not* use the underscore.
> 
> It’s not really a question of good or bad. It’s more a question of what we 
> were required to do to avoid future Cocoa frameworks releases from 
> retroactively breaking our apps.
> 

There were multiple arguments for and against underscores; the namespace issue 
is one of them; readability was another. FWIW, once upon a time, Apple claimed 
the entire namespace prefixed with an underscore as reserved (for both instance 
variables and methods). I believe that the modern runtime does indeed get 
around the issue with ivars (I don’t have a documentation reference to point 
to, but a quick check in Xcode indicates this; as does Charles Srstka’s posted 
code).

—

> On Jun 1, 2015, at 7:11 PM, Charles Srstka  wrote:
> 
> On Jun 1, 2015, at 6:39 PM, Quincey Morris 
>  wrote:
>> 
>> On Jun 1, 2015, at 15:14 , Charles Srstka  wrote:
>>> 
>>> Which is not at all, actually:
>> 
>> The answer is “not at all” only with the modern ABI. 32-bit Mac compilations 
>> will conflict.
> 
> That’s true. Also, code written for the Mac Plus using THINK C 3.0 will 
> conflict. However, compilation targets that people are actually still using 
> in 2015 will not conflict.
> 
> Charl

Re: Looking at self = [super init].

[Michael David Crawford]

Among the reasons I've always preferred Mac development is the common
use of CamelCase.  I have poor eyesight and commonly eye fatigue as
well, that leads to it being difficult for me to distinguish
underscores from hyphens:

   foo = unix_style;
   foo = unix-style;

It is for that same reason that I adopted someone else's practice of
putting spaces inside of parentheses:

   void foo( int x, char y )

I've done that for decades but I've never seen anyone else do it.

On 6/1/15, Britt Durbrow  wrote:
> In no particular order:
>
>> On Jun 1, 2015, at 7:27 PM, Michael David Crawford 
>> wrote:
>>
>> I quite commonly fix bugs by refactoring all the lengthy routines into
>> several shorter ones.
>>
>
>
> I have the same rule of thumb - if it's not obvious what's going on, I
> should probably think about refactoring it into smaller chunks.
>
> --
>
>>
>>
>> On Jun 1, 2015, at 6:09 PM, Graham Cox  wrote:
>>
>> If you have a complex method whose function can't be determined at a
>> glance (and that in itself could be a good argument for a refactoring)
>> with multiple exit points rather than one clear exit point at the end, it
>> can often be hard to follow the flow of control.
>
> Um... don't do that? :-)
>
> Yes, early returns & gotos are power tools that can be misused. YMMV, wear
> proper personal protective equipment, void where prohibited and/or
> uninitialized, not for sale to miners, etc...
>
> ...and no, I have no idea why people who dig ore out of the ground shouldn't
> be allowed to buy it (I suppose that's what I get for asking a muppet for
> legal advice, eh? :-)
>
> --
>
>
>>
>> On Jun 1, 2015, at 4:39 PM, Quincey Morris
>>  wrote:
>>
>> On Jun 1, 2015, at 14:52 , Britt Durbrow
>>  wrote:
>>>
>>> I happen to like an extra semicolon after a closing brace when it's the
>>> end of the logical block. It's just the way I like it to look (it feels
>>> 'funny' to me to have a statement end without one); the compiler ignores
>>> it. YMMV.
>>
>> The issue here is that you may find it comforting to see ';' at the "end"
>> of a statement, but it skates right over the ambiguity of when a "{ ... }"
>> construct is to be regard as a "logical block". The compiler does *not*
>> ignore the ";" after "}". The following does *not* compile:
>>
>>  if (...) {...}; else {...};
>>
>> You can argue that the intermediate ';' not the end of a logical block,
>> but if a "}" isn't the end of a logical block, you've just changed a
>> stylistic rule into a syntax rule.
>>
>
> The entire if statement is what I consider a logical block: the else {...}
> does not, and indeed cannot, stand alone.
>
>   if(someCondition)
>   {
>   [someObject doSomething];
>   }
>   else
>   {
>   [someObject doSomeOtherThing];
>   };
>   
>   [anotherObject doesSomethingElseEntirely];
>
> is the same to the compiler as:
>
>   if(someCondition)
>   {
>   [someObject doSomething];
>   }
>   else
>   {
>   [someObject doSomeOtherThing];
>   }
>   
>   [anotherObject doesSomethingElseEntirely];
>
> or even:
>
>   someCondition?[someObject doSomething]:[someObject
> doSomeOtherThing],[anotherObject doesSomethingElseEntirely];
>
> although I will say that the readability on the third example does suffer
> somewhat. :-)
>
> --
>
>>> I don't use underscores to prefix ivars. I think it's ugly, and
>>> unnecessary -- it doesn't help with namespacing (if a subclass and a
>>> superclass both declare _someVariable with the underscore they will
>>> collide just as badly as if they declare someVariable without one)
>>
>> The real reason for this convention is something else. In the bad old days
>> (meaning, more or less, pre-Leopard), there were multiple conflicting
>> conventions about using "_" for naming. Perhaps it was when the clang
>> compiler was introduced, I can't remember exactly, but Apple decreed the
>> current convention, to work around the inherent unsafety of Obj-C
>> namespacing:
>>
>> -- Private 3rd party instance variables *should* use the underscore.
>>
>> -- Private 3rd party methods *must not* use the underscore.
>>
>> It's not really a question of good or bad. It's more a question of what we
>> were required to do to avoid future Cocoa frameworks releases from
>> retroactively breaking our apps.
>>
>
> There were multiple arguments for and against underscores; the namespace
> issue is one of them; readability was another. FWIW, once upon a time, Apple
> claimed the entire namespace prefixed with an underscore as reserved (for
> both instance variables and methods). I bel

Re: Looking at self = [super init].

[Scott Ribe]

On Jun 1, 2015, at 10:43 PM, Britt Durbrow 
 wrote:
> 
> So…. it looks like clang at least is doing the right thing and calling the 
> destructor when the variable goes out of scope.

Yep. But I believe with goto you can skip over a constructor--but at least you 
get a warning.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice






___

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: Looking at self = [super init].

[Graham Cox]

> On 2 Jun 2015, at 2:51 pm, Michael David Crawford  
> wrote:
> 
> I've done that for decades but I've never seen anyone else do it.


I do. Anyone who’s used any of my public Cocoa code will know this. I even like 
to lay out methods and properties in columns - almost everyone doesn’t so I 
don’t know how that goes down, but my headers are a lot more readable than most.

I have been criticised for my coding style in the past because it “wastes 
space”, but I have far fewer problems coming back to code months or years later 
and seeing what’s what, because everything is clearly laid out.


—Graham



___

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