Re: Looking at self = [super init].

> On Jun 3, 2015, at 8:02 AM, Alex Zavatone wrote: > > On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote: > >> On Jun 1, 2015, at 11:43 PM, Britt Durbrow >> wrote: >>> >>> Although I have the luxury of requiring modern runtime capable systems, >>> some people do still have to target the old r

Re: Looking at self = [super init].

On Jun 3, 2015, at 6:30 AM, Alex Zavatone wrote: > > With that in mind, what should it have depended on instead? His point was not that such dependence was bad, nor even avoidable. His point was that the C++ was a steaming pile ;-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated

Re: Looking at self = [super init].

On Jun 3, 2015, at 9:02 AM, Alex Zavatone wrote: > > On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote: > >> On Jun 1, 2015, at 11:43 PM, Britt Durbrow >> wrote: >>> >> Variables declared in an @interface section trigger a compiler warning: >> >> warning: declaration of instance variables in

Re: Looking at self = [super init].

On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote: > On Jun 1, 2015, at 11:43 PM, Britt Durbrow > wrote: >> >> Although I have the luxury of requiring modern runtime capable systems, some >> people do still have to target the old runtime… > > ARC requires the modern runtime, which has pretty

Re: Looking at self = [super init].

On Jun 2, 2015, at 9:07 PM, Michael David Crawford wrote: > What horrified me was that they were completely unaware that their > product was likely to drop a pickup truck on top of an assembly plant > worker. While the overall architecture had all manner of > fault-tolerance engineered in, that

Re: Looking at self = [super init].

> On Jun 2, 2015, at 12:13 PM, Charles Srstka wrote: > > > Variables declared in an @interface section trigger a compiler warning: > > warning: declaration of instance variables in the interface is deprecated > [-Wobjc-interface-ivars] Hmm… I’ve never seen that warning actually be emitted by

Re: Looking at self = [super init].

While there were numerous reasons for my protest resignation, the reason I walked out - no notice given - was that I was the only one in the company who was aware that there even was such a thing as a C++ Smart Pointer. I knew something was up when I was told to stop referring to the computer prog

Re: Looking at self = [super init].

> On 3 Jun 2015, at 10:19 am, Michael David Crawford > wrote: > > If their coding conventions are > the sort that are likely to lead to correct code The reason for coding style guidelines is a) correctness b) maintainability. If it’s just a fetish that the chief developer has and he can’t ba

Re: Looking at self = [super init].

I once worked for a company that had quite meticulous style rules regarding comments. I was also required to use a specific text editor because someone had written scripts that either enabled or enforced the comment style rules. I resigned in protest because their actual source code is quite like

Re: Looking at self = [super init].

> On 3 Jun 2015, at 9:03 am, Michael David Crawford > wrote: > > "That's because comments are rarely maintained in sync with the actual > source code." > So part of the responsibility of coding well is to maintain comments, not to remove them altogether. At a minimum, I comment what a meth

Re: Looking at self = [super init].

After I pointed out my diligent use of comments to Scott Lydiard, President of aerial photography firm Verde Technologies, he advised me not comment my code in any way. WUT? "That's because comments are rarely maintained in sync with the actual source code." For example: int offset( void ) {

Re: Looking at self = [super init].

On Tue, Jun 2, 2015, at 03:42 PM, Charles Srstka wrote: > > On Jun 2, 2015, at 3:31 PM, Jens Alfke wrote: > > > > I agree, actually. But in Swift the concept of ivar no longer exists, so I > > have to rely on color/style to distinguish properties from locals. > > My solution with Swift is to co

Re: Looking at self = [super init].

> On Jun 2, 2015, at 3:31 PM, Jens Alfke wrote: > >> Anyway, yes, one could ugly up one’s code with italics and boldface and >> whatnot, but simply prefixing the ivar name with an underscore is simpler, >> it prevents accidentally referencing the ivar and/or shadowing it with a >> local variab

Re: Looking at self = [super init].

> On Jun 2, 2015, at 1:28 PM, Charles Srstka wrote: > > Dogs don’t completely lack color vision. Also, calling a person a dog could > really come across in a way that you’re not intending. Sorry, not intended! I was thinking more of “On cocoa-dev, no one knows you’re a dog”. > Anyway, yes, o

Re: Looking at self = [super init].

> On Jun 2, 2015, at 2:41 PM, Jens Alfke wrote: > >> On Jun 2, 2015, at 12:13 PM, Charles Srstka > > wrote: >> >> That can be handy, if you’re not colorblind. If you are, the coloring isn’t >> much help. > > > It depends on what the colors are. Almost no one i

Re: Looking at self = [super init].

Jens, I don't see a setting in the Source Editor's Fonts and Colors that displays a difference between a class's properties and a class's ivars. When you apply a color change or a font change there is no visual differentiation between those two. Honestly, I would love to see the properties on o

Re: Looking at self = [super init].

> On 2 Jun 2015, at 11:02, Jeremy Pereira > wrote: > > >> On 1 Jun 2015, at 19:11, Dave wrote: >> >> >> 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. > > N! >

Re: Looking at self = [super init].

> On Jun 2, 2015, at 12:13 PM, Charles Srstka wrote: > > That can be handy, if you’re not colorblind. If you are, the coloring isn’t > much help. It depends on what the colors are. Almost no one is entirely colorblind; usually it’s just red and green that are problematic. But yes, you might

Re: Looking at self = [super init].

On Jun 1, 2015, at 11:43 PM, Britt Durbrow wrote: > > Although I have the luxury of requiring modern runtime capable systems, some > people do still have to target the old runtime… ARC requires the modern runtime, which has pretty much caused the old one to drop off the map for most people, I

Re: Looking at self = [super init].

> On Jun 1, 2015, at 9:53 PM, Scott Ribe wrote: > > 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 co

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’

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

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

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

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: 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].

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 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 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: 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].

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

> 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: 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 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].

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

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

ac.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:

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

Re: Looking at self = [super init].

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:

Re: Looking at self = [super init].

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

Re: Looking at self = [super init].

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

Re: Looking at self = [super init].

On May 29, 2015, at 11:17 AM, Alex Zavatone wrote: > > On May 29, 2015, at 2:16 PM, Scott Ribe wrote: > >> On May 29, 2015, at 11:49 AM, Alex Zavatone wrote: >>> >>> Would this handle it properly? >>> >>> if (!(self = [super init])) { >>> return nil; >>> } >> >> Yes. >> >>> if (!(self ==

Re: Looking at self = [super init].

On May 29, 2015, at 12:34 PM, Alex Zavatone wrote: > > Then there must be a nice way to step back to the original question and see > if that could be a macro. #define CHECKED_SUPER_INIT if (!(self = [super init])) return nil You *could* wrap it in the do expression to make it workable in if ex

Re: Looking at self = [super init].

On May 29, 2015, at 2:19 PM, Jens Alfke wrote: > Not to mention that putting assignments in ‘if’ statements is EVIL, even if > it does save you a line of code. > > —Jens I tend to agree with you as it makes the code just a little more obtuse. As an example, I went through this entire email t

Re: Looking at self = [super init].

On May 29, 2015, at 12:17 PM, Alex Zavatone wrote: > > Typing == by habit. My mistake. Ah, *NOW* the conversation makes sense ;-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice ___

Re: Looking at self = [super init].

> On May 29, 2015, at 11:02 AM, Alex Zavatone wrote: > > Regarding Daniel's next email, yeah, I kind of really dislike the extra > indent for the entire init function. It just seems so wrong. That’s sort of a religious issue. Some people think early returns from functions are wrong, because

Re: Looking at self = [super init].

On May 29, 2015, at 2:16 PM, Scott Ribe wrote: > On May 29, 2015, at 11:49 AM, Alex Zavatone wrote: >> >> Would this handle it properly? >> >> if (!(self = [super init])) { >> return nil; >> } > > Yes. > >> if (!(self == [super init])) > > No. But not sure whether you were asking about th

Re: Looking at self = [super init].

On May 29, 2015, at 11:49 AM, Alex Zavatone wrote: > > Would this handle it properly? > > if (!(self = [super init])) { >return nil; > } Yes. > if (!(self == [super init])) No. But not sure whether you were asking about that or not… -- Scott Ribe scott_r...@elevated-dev.com http://www.e

Re: Looking at self = [super init].

On May 29, 2015, at 1:42 PM, Quincey Morris wrote: > On May 29, 2015, at 10:35 , Jean-Daniel Dupas wrote: >> >> You must at least returns nil in the fast path, else the compiler will not >> be happy. > > Shame on you, Jean-Daniel, for not spotting the other error! > > On May 29, 2015, at 10:

Re: Looking at self = [super init].

On May 29, 2015, at 1:40 PM, Jean-Daniel Dupas wrote: > >> Le 29 mai 2015 à 19:22, Alex Zavatone a écrit : >> >> Was just looking at good old object initialization and came across a stupid >> idea. >> >> For most object initialization, we do this: >> >> - (id)init { >> if (self = [super i

Re: Looking at self = [super init].

> Il giorno 29/mag/2015, alle ore 19:38, Alex Zavatone ha > scritto: > > DOH. Good catch. Sorry, was typing out by hand instead of copying and > pasting. I'm actually returning nil in the real class. > > So, that should be this: > > - (id)init { >if (self != [super init]) { >r

Re: Looking at self = [super init].

On May 29, 2015, at 10:35 , Jean-Daniel Dupas wrote: > > You must at least returns nil in the fast path, else the compiler will not be > happy. Shame on you, Jean-Daniel, for not spotting the other error! On May 29, 2015, at 10:22 , Alex Zavatone wrote: > >if (self != [super init]) { >

Re: Looking at self = [super init].

On May 29, 2015, at 1:35 PM, Jean-Daniel Dupas wrote: > >> Le 29 mai 2015 à 19:22, Alex Zavatone a écrit : >> >> Was just looking at good old object initialization and came across a stupid >> idea. >> >> For most object initialization, we do this: >> >> - (id)init { >> if (self = [super i

Re: Looking at self = [super init].

> Le 29 mai 2015 à 19:22, Alex Zavatone a écrit : > > Was just looking at good old object initialization and came across a stupid > idea. > > For most object initialization, we do this: > > - (id)init { >if (self = [super init]) { >// Set up stuff here. >// this could get

Re: Looking at self = [super init].

> Le 29 mai 2015 à 19:22, Alex Zavatone a écrit : > > Was just looking at good old object initialization and came across a stupid > idea. > > For most object initialization, we do this: > > - (id)init { >if (self = [super init]) { >// Set up stuff here. >// this could get