RE: NSPathControl

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

RE: Looking at self = [super init].

> 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

Re: Looking at self = [super init].

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

Re: [PSA] OSStatus.com -- Error code lookup

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 >

Re: [PSA] OSStatus.com -- Error code lookup

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

Concatenating two NSIndexPath objects

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 g

Re: Looking at self = [super init].

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

Re: NSPathControl

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_A

Re: NSPathControl

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

Re: NSPathControl

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

Re: Concatenating two NSIndexPath objects

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

Re: Looking at self = [super init].

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

Re: Looking at self = [super init].

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

Re: Looking at self = [super init].

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 ht

Re: Looking at self = [super init].

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 u

Re: Looking at self = [super init].

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 rol

Re: Looking at self = [super init].

> 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

Re: NSPathControl

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

Re: Looking at self = [super init].

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

Re: Looking at self = [super init].

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/

Re: Looking at self = [super init].

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

Re: Looking at self = [super init].

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

Re: NSPathControl

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

Re: Looking at self = [super init].

> 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

Re: Looking at self = [super init].

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 contin

Re: Looking at self = [super init].

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,

Re: Looking at self = [super init].

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:

Re: NSPathControl

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

Re: Looking at self = [super init].

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 refac

Re: Looking at self = [super init].

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 tha

Re: Looking at self = [super init].

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 scot

Re: Looking at self = [super init].

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