We desperately need *Value methods in the Swift template. #219

Closed
Scenario opened this Issue Jul 10, 2014 · 6 comments

Comments

Projects
None yet
5 participants

The Swift compiler in Xcode Beta 3 still doesn't play well with the Cocoa classes produced by mogenerator. It requires us to use KVC exclusively to get or set any property in an NSManagedObject entity, and that is a major burden on us lowly devs.

In Objective-C, the .h/.m files generated by mogenerator produce type-safe convenience getters and setters of the form "myPropertyValue". But those are all missing from the Swift template in 1.28.

Please consider adding these unless there's a good reason not to. :)

Scenario changed the title from We desperately need *Value support in the Swift template. to We desperately need *Value methods in the Swift template. Jul 10, 2014

Actually now I think the Swift template should be declaring numeric values as NSNumber — not Int16, Int32, Int64, Double, Float, etc. This is causing major problems.

Checking the template for Cocoa, NSValue was used. Not sure why you guys would think Swift should be different...

Now I'm not so sure which way is better. Certainly there is a consistency issue with the Obj-C legacy, which used NSValue. But the scalars are proving to be cleaner in Swift.

Perhaps a mogenerator option is warranted here? I think I saw someone else mention that too.

Owner

rentzsch commented Jul 24, 2014

The (working) Swift templates on the 1.28 branch is using NSNumber?. This allows things like setting the attribute to nil, which otherwise Swift won't allow.

Now I'm thinking even the Swift templates need *Value boxing/unboxing convenience methods.

how bout:

if the model has the attribute designated as optional, use a normal optional scalar type like Int?
if the model has the attribute designated as non-optional, use an implicitly unwrapped optional scalar like Int!

Agreed, right now I just get crashes since swift tries to access nil non-optionals

Collaborator

justin commented Dec 26, 2015

We are working on adjusting how we generate Swift in #302. If you have feedback, let's put it there.

justin closed this Dec 26, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment