> On Jun 4, 2015, at 9:16 AM, Uli Kusterer wrote:
>
>
>> On 04 Jun 2015, at 02:36, Britt Durbrow
>> wrote:
>>
>>
>>> On Jun 3, 2015, at 11:30 AM, Mark Wright wrote:
>>>
>>> For what it’s worth, I’ve never had that problem either. Most of the time
>>> self.whatever is used for property a
> On 04 Jun 2015, at 02:36, Britt Durbrow
> wrote:
>
>
>> On Jun 3, 2015, at 11:30 AM, Mark Wright wrote:
>>
>> For what it’s worth, I’ve never had that problem either. Most of the time
>> self.whatever is used for property access, _whatever is used for ivar access
>> and that’s about it.
On 03 Jun 2015, at 20:30, Mark Wright wrote:
> I believe Uli is mistaken on this point, I’m pretty sure Apple actually
> recommends prefixing your own ivars in this manner (hence the way auto
> property synthesis works), it’s *methods* that generally shouldn’t be
> prefixed with an underscore (
> On Jun 3, 2015, at 11:30 AM, Mark Wright wrote:
>
> For what it’s worth, I’ve never had that problem either. Most of the time
> self.whatever is used for property access, _whatever is used for ivar access
> and that’s about it.
Yup. This is what I meant about properties vs ivars being obvi
> On 03 Jun 2015, at 19:54, Alex Zavatone wrote:
>
>
> On Jun 3, 2015, at 2:30 PM, Mark Wright wrote:
>
>> The only potential problem is ivars that don’t have the leading underscore.
>
> My project has 377 of them. All named the same as the property, if there is
> a property to begin with.
On Jun 3, 2015, at 2:30 PM, Mark Wright wrote:
> The only potential problem is ivars that don’t have the leading underscore.
My project has 377 of them. All named the same as the property, if there is a
property to begin with. That's why I'm walking down this fun little road.
_
> On 03 Jun 2015, at 18:59, Uli Kusterer wrote:
>
> On 03 Jun 2015, at 19:09, Alex Zavatone wrote:
>> On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
>>
>>> So you're not supposed to use the underscore convention even for your
>>> private ivars, as Apple could add secret stuff to NSObject or
On Jun 3, 2015, at 1:59 PM, Uli Kusterer wrote:
> On 03 Jun 2015, at 19:09, Alex Zavatone wrote:
>> On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
>>
>>> So you're not supposed to use the underscore convention even for your
>>> private ivars, as Apple could add secret stuff to NSObject or an
On 03 Jun 2015, at 19:09, Alex Zavatone wrote:
> On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
>
>> So you're not supposed to use the underscore convention even for your
>> private ivars, as Apple could add secret stuff to NSObject or any other base
>> class you'd collide with.
>>
>> -- Uli
On 03 Jun 2015, at 19:06, Alex Zavatone wrote:
> On Jun 3, 2015, at 12:46 PM, Mark Wright wrote:
>
>> This is important and is all about *scope*.
>>
>> A class’s properties are only public if they’re in the header.
>
> Exactly.
>
> With that said, why do we not have a convention with propertie
On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
> So you're not supposed to use the underscore convention even for your private
> ivars, as Apple could add secret stuff to NSObject or any other base class
> you'd collide with.
>
> -- Uli
So, how are we expected to tell the private/public/iva
On Jun 3, 2015, at 12:46 PM, Mark Wright wrote:
> This is important and is all about *scope*.
>
> A class’s properties are only public if they’re in the header.
Exactly.
With that said, why do we not have a convention with properties declared within
the .m file for showing that they are priva
> On 03 Jun 2015, at 18:46, Mark Wright wrote:
>
>
>> On 03 Jun 2015, at 17:08, Alex Zavatone wrote:
>>
>>
>> One point I haven't looked at is, "if @properties are declared within the
>> @implementation or the class extension, are they private? And if so,
>> shouldn't they be preceded wit
> On 03 Jun 2015, at 17:08, Alex Zavatone wrote:
>
>
> One point I haven't looked at is, "if @properties are declared within the
> @implementation or the class extension, are they private? And if so,
> shouldn't they be preceded with an underscore and in that case, what does
> that make the
Here's what I found to be great places to start from within one of Apple's docs.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
Essential reading
Page 16:
Page 43:
Page 73: Use Class Extensions to Hide Private Info
My question was unclear. I was asking about _where_ they should be declared. I
guess they remain in the @interface.
Le 3 juin 2015 à 18:11, Mark+Vron a écrit :
>> On 03 Jun 2015, at 16:27, Bernard Desgraupes wrote:
>>
>>
>> What about the @property declarations in the new scheme ?
>>
>
>
> On 03 Jun 2015, at 16:27, Bernard Desgraupes wrote:
>
>
> What about the @property declarations in the new scheme ?
>
>
I’m not sure what you’re asking, @properties are a big part of the 'new way'…
This is not about properties though, just about the notion of moving ivars out
of the cla
> On Jun 3, 2015, at 8:27 AM, Bernard Desgraupes wrote:
>
>
> What about the @property declarations in the new scheme ?
You can add @property declarations in any @interface block. Properties added in
a class extension will be automatically synthesized. Properties added via a
protocol (declar
On Jun 3, 2015, at 11:27 AM, Bernard Desgraupes wrote:
>
> What about the @property declarations in the new scheme ?
>
Well, from what I've read, Apple wants you to use @properties over declaring
ivars. But… I don't know.
With auto-synthesis, you get ivars for free.
One point I haven't loo
On Jun 3, 2015, at 11:15 AM, Mark Wright wrote:
> Sorry, yes, I misread the initial paragraph that mentions the @implementation
> block. I actually meant implementation *file* since that’s typically where
> the class extension @interface is declared (it extends the class internally).
>
> Howe
What about the @property declarations in the new scheme ?
Le 3 juin 2015 à 17:15, Mark Wright a écrit :
> Sorry, yes, I misread the initial paragraph that mentions the @implementation
> block. I actually meant implementation *file* since that’s typically where
> the class extension @interf
Sorry, yes, I misread the initial paragraph that mentions the @implementation
block. I actually meant implementation *file* since that’s typically where the
class extension @interface is declared (it extends the class internally).
However, as you’ve surmised, all this talk of clang warnings reg
On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
> There are 3 ways to add ivars to a class. The traditional way:
>
> @interface Foo {
> id _bar;
> }
>
> And 2 new ways:
>
> @interface Foo() { // Class extension, note the ()
> id _baz;
> }
Ahhh. Completely missed that. Haven
There are 3 ways to add ivars to a class. The traditional way:
@interface Foo {
id _bar;
}
And 2 new ways:
@interface Foo() { // Class extension, note the ()
id _baz;
}
@implementation Foo { // Implementation block.
id _faz;
}
> On Jun 3, 2015, at 7:32 AM, Alex Zavatone
Maybe I should have included the text above it.
"It's also possible to use a class extension to add custom instance
variables. These are declared inside braces in the class extension interface."
So, I don't know how you see that it goes in the @implementation block since
the code I pasted and
That’s a ‘Class Extension’. Furthermore, it’s under the title "Class
Extensions Extend the Internal Implementation”. It also mentions that it goes
in the @implementation block…
> On 03 Jun 2015, at 15:11, Alex Zavatone wrote:
>
> Apple's Programming with Objective-C reference document © 2
I’m fairly certain the warning is newer than the documentation.
> On Jun 3, 2015, at 7:11 AM, Alex Zavatone wrote:
>
> Apple's Programming with Objective-C reference document © 2014
>
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingW
Apple's Programming with Objective-C reference document © 2014
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
Page 73
@interface XYZPerson () {
id _someCustomInstanceVariable;
}
...
@end
Uhh.
Doesn't thi
28 matches
Mail list logo
