Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Better optional property behavior and other enhancements to Swift support #245

Closed
wants to merge 6 commits into from
Closed

Better optional property behavior and other enhancements to Swift support #245

wants to merge 6 commits into from

Commits on Sep 2, 2014

  1. Make NSNumbers non-optional for non-optional attributes 

    Objects are guaranteed to be binary-compatible whether they're optional
or not, so this difference is invisible to Core Data.
    @beccadax
    beccadax committed Sep 2, 2014
    Configuration menu
    Copy the full SHA
    a653b76 View commit details
    Browse the repository at this point in the history

  2. Human-readable files need an import statement too 

    Otherwise they can't use, for instance, NSManagedObjectContext.
    @beccadax
    beccadax committed Sep 2, 2014
    Configuration menu
    Copy the full SHA
    cb09202 View commit details
    Browse the repository at this point in the history

  3. Add means to access mutable versions of relationships

    @beccadax
    beccadax committed Sep 2, 2014
    Configuration menu
    Copy the full SHA
    48b1b9b View commit details
    Browse the repository at this point in the history

  4. Match Obj-C mutable collection accessors 

    In terms of both name and behavior.
    @beccadax
    beccadax committed Sep 2, 2014
    Configuration menu
    Copy the full SHA
    a39cddf View commit details
    Browse the repository at this point in the history

  5. Move logic for choosing optional character into Objective-C 

    The templates are pretty convoluted, and will get more so with the next
commit.
    @beccadax
    beccadax committed Sep 2, 2014
    Configuration menu
    Copy the full SHA
    a95b7e6 View commit details
    Browse the repository at this point in the history

  6. Further refine application of optionals to properties 

    Until now, mogenerator's nil behavior has been an approximation of the
truth, because Core Data's "optional" is a bit different from Swift's
"optional". Basically, Core Data non-optionals can't be *saved* with
nil in them, while Swift non-optionals can't be *set* to nil at any
point.

There are four circumstances in which a "non-optional" Core Data
property can be nil:

1. If it is an attribute with no default value, or a to-one
relationship, the property will be nil upon initialization.

2. If a to-one relationship's inverse specifies a "nullify" rule, the
to-one relationship will temporarily become nil when the destination
object is deleted.

3. Objective-C code or setValue(_:forKey:) could set a property to nil
temporarily.

4. After an object is deleted and its context is saved, all of its
properties become nil.

To be fully correct, all Core Data properties would have to be either
optional (?) or implicit optional (!) in Swift. However, I don't think
3 and 4 are really worth worrying about very much. 3 involves
intentionally making a valid object graph invalid, and 4 involves
access to a permanently deleted object with no usable data. I don't
think either of these are worth losing much sleep over.

That leaves the first two cases. In 1, Core Data displays two-phase
initialization behavior. The recommended way of handling two-phase
initialization is an implicitly unwrapped optional. In 2, the nil
should probably be resolved by the same code that caused the problem,
so it should be very transient.

So the solution I took was to use implicit optionals to cover those two
cases, and ignore the other two. Properties marked optional in Core
Data are, of course, regular optionals in Swift as well.
    @beccadax
    beccadax committed Sep 2, 2014
    Configuration menu
    Copy the full SHA
    4a11e53 View commit details
    Browse the repository at this point in the history