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
25 matches
Mail list logo
