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
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
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
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
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
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
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
Hi, I'm using WebView and I'd like to enable HTML5 local storage.
I've read some questions on Stack Overflow where the suggestion is to do:
WebPreferences *prefs = [webView preferences];
[prefs _setLocalStorageDatabasePath:@"~/Library/Application
Support/MyApp"];
[prefs setLocalStorag
On Jun 3, 2015, at 8:23 AM, Juanjo Conti wrote:
>
> Hi, I'm using WebView and I'd like to enable HTML5 local storage.
>
> I've read some questions on Stack Overflow where the suggestion is to do:
>
> WebPreferences *prefs = [webView preferences];
> [prefs _setLocalStorageDatabasePath:@"
Same error with both names.
On Wed, Jun 3, 2015 at 11:31 AM, Scott Ribe
wrote:
> On Jun 3, 2015, at 8:23 AM, Juanjo Conti wrote:
> >
> > Hi, I'm using WebView and I'd like to enable HTML5 local storage.
> >
> > I've read some questions on Stack Overflow where the suggestion is to do:
> >
> >
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
BTW; I get the error in both lines.
On Wed, Jun 3, 2015 at 11:35 AM, Juanjo Conti
wrote:
> Same error with both names.
>
> On Wed, Jun 3, 2015 at 11:31 AM, Scott Ribe
> wrote:
>
>> On Jun 3, 2015, at 8:23 AM, Juanjo Conti
>> wrote:
>> >
>> > Hi, I'm using WebView and I'd like to enable HTML5 l
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
> On 3 Jun 2015, at 22:23, Juanjo Conti wrote:
>
> Hi, I'm using WebView and I'd like to enable HTML5 local storage.
>
> I've read some questions on Stack Overflow where the suggestion is to do:
>
>WebPreferences *prefs = [webView preferences];
>[prefs _setLocalStorageDatabasePath:@"~/
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
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
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
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
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 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 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
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 ?
>>
>
>
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
> 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
> 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 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 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 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 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 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 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 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 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
> 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.
I have two questions I'm hoping I can get some advice on...
First the complicated one:
I have an NSTableView (cell-based) in which I am trying to rig two
columns with NSPopupButtonCell - the selection in the first one
determines the possible values of the second.
This is part of a document
> On 4 Jun 2015, at 7:29 am, Frank D. Engel, Jr. wrote:
>
> Now what I am hoping is the simpler one:
>
> I have a custom subclass of NSTextFieldCell which I am using to show an icon
> in an NSBrowser. The icon image is being generated dynamically by a method
> in my subclass and I want it to
I based my code on one of Apple's examples and had tried using
NSBrowserCell but was not able to get that working; I assume there is
some reason why Apple chose to use NSTextFieldCell in their example and
I followed suit.
Currently, I have this coded - I had tried several variations to force
After all of this, I finally at least partially solved this one.
I added a line of code to run each time that method is called.
It wasn't being called most of the time. I found where I was calling
this and changed the code a bit to use a binding created by code, and
now it is almost working.
> On 4 Jun 2015, at 10:20 am, Frank D. Engel, Jr. wrote:
>
> I am wondering if the browser is actually caching an image of the cells in
> the second column when I switch away, then just displaying that without
> actually recreating the cells in the second column until it needs one of them
> f
> 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
40 matches
Mail list logo
