On Jan 27, 2015, at 17:21 , Jerry Krinock wrote:
>
> Compiler does *not* warn if you have a custom primitive setter without a
> getter.
FWIW, the compiler doesn’t warn you if you have any setter without a getter.
> I also tried to get it to compile without declaring the instance variable
> th
> On 2015 Jan 27, at 12:44, Keary Suska wrote:
>
> What exactly happened when you specified the setter, but not the getter?
I said I wasn’t sure because the project has a bunch of warnings due to ongoing
major rework, but I just retested again. Answer: Compiler does *not* warn if
you have a
> On Jan 27, 2015, at 1:34 PM, Quincey Morris
> wrote:
>
> FWIW, there is yet another way to get to backing store from a custom
> primitive accessor — define another, private, Core Data property, and use
> *its* primitive accessors. This may seem clunky, but it’s officially
> countenanced in
> On Jan 27, 2015, at 1:34 PM, Quincey Morris
> wrote:
>
> On Jan 27, 2015, at 11:06 , Richard Charles wrote:
>>
>> That is a key-value coding method.
>
> It’s not, as Kyle just said.
Okay, you both win. It is a method which supports key-value coding.
Richard Charles
___
On Jan 27, 2015, at 12:44 , Keary Suska wrote:
>
> That part of the conversation was private between you and Quincey. I am
> simply curious as I can't imagine why one would want to.
It wasn’t intentionally private. It was just one of those cases where a post
with a lot of invisible formatting
On Jan 27, 2015, at 9:52 AM, Jerry Krinock wrote:
>
>> On 2015 Jan 27, at 06:46, Keary Suska wrote:
>>
>> Better, however, to have a property declaration, which would also synthesize
>> an ivar in modern LLVMs (as of Xcode 5?).
>
> You mean the property declaration would synthesize the ivar.
On Jan 27, 2015, at 11:06 , Richard Charles wrote:
>
> That is a key-value coding method.
It’s not, as Kyle just said.
FWIW, there is yet another way to get to backing store from a custom primitive
accessor — define another, private, Core Data property, and use *its* primitive
accessors. Thi
On Tue, Jan 27, 2015, at 01:06 PM, Richard Charles wrote:
>
> > On Jan 27, 2015, at 11:28 AM, Kyle Sluder wrote:
> >
> > Historically, I've not been a big Core Data user, but does
> > -[NSManagedObject setPrimitiveValue:forKey:] not do what you want?
>
> That is a key-value coding method.
No i
> On Jan 27, 2015, at 11:28 AM, Kyle Sluder wrote:
>
> Historically, I've not been a big Core Data user, but does
> -[NSManagedObject setPrimitiveValue:forKey:] not do what you want?
That is a key-value coding method. If I remember correctly, key-value coding
does not bypass existing accessor
On Tue, Jan 27, 2015, at 12:21 PM, Richard Charles wrote:
> You can’t override a primitive accessor because one is dynamically
> generated for you at runtime if it is needed. If a custom primitive
> accessor is implemented then the managed object subclass must provide an
> ivar for backing storage.
> On Jan 27, 2015, at 2:24 AM, Quincey Morris
> wrote:
>
> Clearly, all this customization takes some coordination between steps 1 and
> 2, even if it’s just to know which of them needs to be customized in any
> particular case, and how. That where the documentation falls down — it gives
> r
> On 2015 Jan 27, at 06:46, Keary Suska wrote:
>
> Better, however, to have a property declaration, which would also synthesize
> an ivar in modern LLVMs (as of Xcode 5?).
You mean the property declaration would synthesize the ivar. I didn’t try
that. I agree it would be better.
>> It stil
> On 2015 Jan 27, at 01:24, Quincey Morris
> wrote:
>
> I’m not sure that it’s “bad”, though it is nontypical, which is why there’s a
> [nontypical] custom accessor. a Core Data property access has two general
> steps … you can customize one or both of these steps.
OK, the documentation writ
> What in the world is that nonCompliantKVCivar? I tried it in my project, on
> the ‘rating’ property as in my YouTube video.
>
> - (void)setPrimitiveRating:(NSNumber*)newRating {
>rating = newRating ;
> }
>
> Does not compile. The compiler never heard of ‘rating’. Same result if I
> cha
On Jan 26, 2015, at 23:32 , Jerry Krinock wrote:
>
> You seem to be saying that the only example given by Apple is a bad example,
> because it is a a nontypical, special case. I mean, most attributes in most
> apps are objects, not scalars.
I’m not sure that it’s “bad”, though it is nontypic
> On 2015 Jan 26, at 22:14, Quincey Morris
> wrote:
>
> On Jan 26, 2015, at 17:55 , Jerry Krinock wrote:
>>
>> What in the world is that nonCompliantKVCivar?
>
> It’s just an ivar that was defined separately from this particular code
> fragment. It’s “non compliant” because Core Data does
On 2015 Jan 26, at 16:10, Richard Charles wrote:
> It is not uncommon for this application to work with large data sets. I
> tested using KVO on a managed object property and undo took 34 seconds. I
> implemented custom accessors (public and primitive) containing custom change
> code and undo
> On Jan 26, 2015, at 12:10 PM, Jerry Krinock wrote:
>
>
> On 2015 Jan 26, at 07:00, Richard Charles wrote:
>
>> Where do you post the notification from for a managed object property change?
>
> Just to clarify: Your question refers to how I do it in my real apps, using
> NSNotificationCent
On 2015 Jan 26, at 07:00, Richard Charles wrote:
> Where do you post the notification from for a managed object property change?
Just to clarify: Your question refers to how I do it in my real apps, using
NSNotificationCenter, not how I did it in the YouTube video, which was
demonstating KVO.
> On 26 Jan 2015, at 15:00, Richard Charles wrote:
>
>
>> On Jan 25, 2015, at 4:16 PM, Jerry Krinock wrote:
>>
>> The reason I had to run that test is because I don’t use KVO for observing
>> managed object properties. Instead, I use NSNotificationCenter, which has
>> these advantages…
>
> On Jan 25, 2015, at 4:16 PM, Jerry Krinock wrote:
>
> The reason I had to run that test is because I don’t use KVO for observing
> managed object properties. Instead, I use NSNotificationCenter, which has
> these advantages…
Where do you post the notification from for a managed object prop
> On 2015 Jan 25, at 22:03, Kyle Sluder wrote:
>
> On Sun, Jan 25, 2015, at 05:16 PM, Jerry Krinock wrote:
>> • When an observer is being torn down you can remove all observers with
>> one line of code,
>> [NSNotificationCenter removeObserver:self].
> This is a dangerous API. If your super
On Sun, Jan 25, 2015, at 05:16 PM, Jerry Krinock wrote:
• Amount of code required is the same or less
> • Ability to coalesce and filter notifications per object or name
> • When an observer is being torn down you can remove all observers with
> one line of code,
> [NSNotificationCenter remove
On 2015 Jan 25, at 01:20, Mike Abdullah wrote:
> You are mistaken. Core Data *does* fire KVO notifications during undo/redo.
Although I wasn’t aware of this, I just did a little experiment and found that
Mike is correct…
http://youtu.be/PUHBAq-Me_4
On 25 Jan 2015, at 06:35, Richard Charles
> On 25 Jan 2015, at 06:35, Richard Charles wrote:
>
> Core Data generated primitive accessors are used to get and set values from
> and to the managed object's private internal store. Core Data generated
> primitive accessors do not have change notification. If primitive accessors
> are pres
Core Data generated primitive accessors are used to get and set values from and
to the managed object's private internal store. Core Data generated primitive
accessors do not have change notification. If primitive accessors are present,
Core Data will use them during undo and redo.
A managed ob
26 matches
Mail list logo
