On Jun 4, 2015, at 9:16 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote:
On 04 Jun 2015, at 02:36, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
On Jun 3, 2015, at 11:30 AM, Mark Wright blue.bucon...@virgin.net wrote:
For what it’s worth, I’ve never had that
On 03 Jun 2015, at 20:30, Mark Wright blue.bucon...@virgin.net 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
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 19:54, Alex Zavatone z...@mac.com 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
On Jun 3, 2015, at 11:30 AM, Mark Wright blue.bucon...@virgin.net 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
I’m fairly certain the warning is newer than the documentation.
On Jun 3, 2015, at 7:11 AM, Alex Zavatone z...@mac.com wrote:
Apple's Programming with Objective-C reference document © 2014
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
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
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
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 z...@mac.com wrote:
Apple's Programming with Objective-C reference
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't seen it
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).
However,
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
On 03 Jun 2015, at 16:27, Bernard Desgraupes bdesgrau...@orange.fr 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
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
What about the @property declarations in the new scheme ?
Le 3 juin 2015 à 17:15, Mark Wright blue.bucon...@virgin.net 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
On Jun 3, 2015, at 8:27 AM, Bernard Desgraupes bdesgrau...@orange.fr 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
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
On 03 Jun 2015, at 17:08, Alex Zavatone z...@mac.com 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
On 03 Jun 2015, at 18:46, Mark Wright blue.bucon...@virgin.net wrote:
On 03 Jun 2015, at 17:08, Alex Zavatone z...@mac.com 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
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 private
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 mark.v...@virgin.net a écrit :
On 03 Jun 2015, at 16:27, Bernard Desgraupes bdesgrau...@orange.fr wrote:
What about the @property
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
On Jun 3, 2015, at 1:59 PM, Uli Kusterer wrote:
On 03 Jun 2015, at 19:09, Alex Zavatone z...@mac.com 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 03 Jun 2015, at 18:59, Uli Kusterer witness.of.teacht...@gmx.net wrote:
On 03 Jun 2015, at 19:09, Alex Zavatone z...@mac.com 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
On 03 Jun 2015, at 19:06, Alex Zavatone z...@mac.com 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
On 03 Jun 2015, at 19:09, Alex Zavatone z...@mac.com 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.
--
27 matches
Mail list logo
