No mapping if value from custom boxing is nil

[fonkadelic]

If the value from a boxing method (e.g. in a custom category) returns nil no mapping on the instance happens and the old value persists. (see: https://github.com/krzysztofzablocki/KZPropertyMapper/blob/master/KZPropertyMapper/KZPropertyMapper.m#L164)

Is there any chance to set a property to nil for custom boxed value?

[krzysztofzablocki]

what if you return NSNull ?

[fonkadelic]

An exception is thrown:
Invalid condition not satisfying: isSameTypeObject'

[krzysztofzablocki]

hmm, can you comment out the type checking just to see if NSNull works to nil out the variable without it ? I don't remember if that should work or not in KVC, can't test this moment.

If it works then we can make an exception for NSNull type for pointer properties

[fonkadelic]

After disabling type checking there is an NSInvalidArgumentException: Unacceptable type of value for attribute: property = "dayOfBirth"; desired type = NSDate; given type = NSNull; value = <null>.

I'm pretty sure this happens only because i'm using a NSManagedObject. For a regular NSObject the mapping probably works.

[krzysztofzablocki]

ok, I think we can give NSNull special meaning for boxing, since I doubt we have other use case for it than marking something as failed, so in recap:

• Allow NSNull to pass type validation for object properties
• Unwrap NSNull into nil before setValue forKeyPath

I'll have some time over this weekend to implement it, if you are in a hurry I always like PR's :)

I'll probably do it with support for NSError as well, so we can fail validation if a KZCall/Boxing is considered invalid as described in #53
Any thoughts?

[fonkadelic]

Are you already working on this? If not, i can try to come up with a PR with the 2 points you mentioned in the next days.

[krzysztofzablocki]

Go ahead as I'll be in London for next couple of days

On Wed, Nov 25, 2015 at 8:09 PM, Bernhard Loibl [email protected]
wrote:

Are you already working on this? If not, i can try to come up with a PR with the 2 points you mentioned in the next days.

Reply to this email directly or view it on GitHub:
#54 (comment)