Apologies for the mis-post, was supposed to be posted to a different thread.
Not sure if it was me or Mail that had a mis-fire but I’ll blame “Mail” lol.
Cheers
Dave
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin req
HI,
A bit more on this, firstly the problem seems to be related to the
ImageAndTextCell class and secondly looking at the awakeFromNIB method from
SourceView, ImageAndTextCell is allocated, the property is set, but then it
does nothing with it. I assume that under ARC ImageAndTextCell will be s
> On 27 May 2015, at 13:37, Alex Zavatone wrote:
>
>
> On May 27, 2015, at 6:08 AM, Uli Kusterer wrote:
>
>> On 26 May 2015, at 19:24, Alex Zavatone wrote:
>>> For any nonmutable class, should I be using copy instead of strong or is
>>> this just with NSString?
>>
>> You should consider tha
On May 27, 2015, at 6:08 AM, Uli Kusterer wrote:
> On 26 May 2015, at 19:24, Alex Zavatone wrote:
>> For any nonmutable class, should I be using copy instead of strong or is
>> this just with NSString?
>
> You should consider that pattern for every class for which a mutable version
> exists t
> With regards to understanding what is going on in the 4000 line view
> controllers, the areas that were problematic for me were where the instance
> variables were declared in the interface as someProperty (or as Someproperty,
> ugh) and then the property was declared and manually synthesized
On 26 May 2015, at 19:24, Alex Zavatone wrote:
> For any nonmutable class, should I be using copy instead of strong or is this
> just with NSString?
You should consider that pattern for every class for which a mutable version
exists that is a subclass of the non-mutable base class (because onl
> On May 26, 2015, at 10:24 AM, Alex Zavatone wrote:
>
> For any nonmutable class, should I be using copy instead of strong or is this
> just with NSString?
Well, only for classes that implement NSCopying. And if it’s truly an immutable
value class; for example you probably wouldn’t want an I
On May 26, 2015, at 1:00 PM, Fritz Anderson wrote:
>
> On 22 May 2015, at 7:49 AM, Alex Zavatone wrote:
>
>> @property (nonatomic, strong) NSString *thing;
>>
>
> Another chore in porting this code: The retention attribute should be copy,
> not strong.
I just typed that off the top of my h
On 22 May 2015, at 7:49 AM, Alex Zavatone wrote:
> @property (nonatomic, strong) NSString *thing;
>
Another chore in porting this code: The retention attribute should be copy, not
strong.
If you needed to track changes in the string, you'd use strong, but NSStrings
don’t mutate; NSMutableSt
On 22 May 2015, at 14:49, Alex Zavatone wrote:
> Thanks for the wake up call, UIi!
I’m sorry. I’d much rather get you the news that you can sleep in :-)
Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de
___
Co
AHA. I am incorrect.
Now in the office, when reviewing my code in the test, I wasn't testing
auto-synthesis of the properties. Now that I am, I can see that
auto-synthesized properties DO create the ivar with the leading underscore.
Stepping back to my original question, the code that I am re
On May 22, 2015, at 3:43 AM, Uli Kusterer wrote:
> On 21 May 2015, at 19:55, Quincey Morris
> wrote:
>> On May 21, 2015, at 10:40 , Fritz Anderson wrote:
>>>
>>> I must have misinterpreted the question. I had understood Alex wanted a
>>> build option to turn off the auto-synthesis of propert
On 21 May 2015, at 19:55, Quincey Morris
wrote:
> On May 21, 2015, at 10:40 , Fritz Anderson wrote:
>>
>> I must have misinterpreted the question. I had understood Alex wanted a
>> build option to turn off the auto-synthesis of properties, so the compiler
>> could complain at every conflation
> On May 21, 2015, at 10:40 AM, Fritz Anderson wrote:
>
> I must have misinterpreted the question. I had understood Alex wanted a build
> option to turn off the auto-synthesis of properties, so the compiler could
> complain at every conflation of ivars with @propertys.
The warning causes the
On May 21, 2015, at 10:40 , Fritz Anderson wrote:
>
> I must have misinterpreted the question. I had understood Alex wanted a build
> option to turn off the auto-synthesis of properties, so the compiler could
> complain at every conflation of ivars with @propertys.
You didn’t misinterpret the
On 21 May 2015, at 12:27 PM, Kyle Sluder wrote:
>
> On Thu, May 21, 2015, at 12:11 PM, Alex Zavatone wrote:
>> Jens mentioned that it was possible to turn off the auto-synthesis of
>> properties in the build options of the target.
>>
>> This would be quite useful to help me iron out items that n
On Thu, May 21, 2015, at 12:11 PM, Alex Zavatone wrote:
> Jens mentioned that it was possible to turn off the auto-synthesis of
> properties in the build options of the target.
>
> This would be quite useful to help me iron out items that need to be
> refactored in my current project.
>
> My goog
Jens mentioned that it was possible to turn off the auto-synthesis of
properties in the build options of the target.
This would be quite useful to help me iron out items that need to be refactored
in my current project.
My google skills are weak. I can't find out how to do this. Anyone care t
18 matches
Mail list logo
