> On 28 May 2015, at 17:56, Kyle Sluder wrote:
>
> On Thu, May 28, 2015, at 08:37 AM, Dave wrote:
>> Hi,
>>
>> This is from Apple Sample Code so I thought something as fundamental as
>> this would have been dealt with correctly. This is the copy method inside
>> the “ImageAndTextCell” class,
>>
> On 29 May 2015, at 2:03 pm, Jerry Krinock wrote:
>
> But Graham’s GCVolumeControl is still way better than circular NSSlider no
> matter how you rotate it.)
Kind of you Jerry. Make sure you grab the latest if you intend to use it - I
made a useful number of improvements over the first vers
I am printing my NSTableView by constructing an NSTextTable attributed string
representation and storing that into an NSTextView.
This works great and it paginates correctly :i.e.: table rows don’t get split
between pages.
My NSTextTable has a header row and this is output at the start of each t
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 long.
}
return self;
}
in some cases, the set up within the
> 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
> 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
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
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]) {
>
> 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
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
Good to know. Duplicate radar filed, rdar://problem/21145343.
We saw the same issue starting with 10.10.3 and continuing through current
10.10.4 builds. Write up a radar and reference radar://problem/20368338 as a
duplicate instance.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/
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:
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
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
> 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
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
___
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
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
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 ==
> 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
20 matches
Mail list logo
