Some tweaks to the machine.swift.motemplate

[DaveWoodCom]

Fixes a few issues I came across while trying out the swift modifications.

[grasmeyer]

I experienced the same problems, but I ended up implementing entityName as a class var. It makes the syntax cleaner, since you don't need the extra () for the method. Also, your update to the convenience init method has problems when using a base class. See the code below

class var entityName: String {
    return "<$name$>"
}

init(entity: NSEntityDescription!, insertIntoManagedObjectContext context: NSManagedObjectContext!) {
    super.init(entity: entity, insertIntoManagedObjectContext: context)
}

convenience init(managedObjectContext: NSManagedObjectContext!) {
    let entity = NSEntityDescription.entityForName("<$name$>", inManagedObjectContext: managedObjectContext)
    self.init(entity: entity, insertIntoManagedObjectContext: managedObjectContext)
}

[grasmeyer]

I found a problem with the code listed in the comment above. Returning entityName as a class var won't work because Swift doesn't allow a class var to override more than one superclass declaration. This is a problem if the base class, an abstract entity, and a subentity all declare entityName as a class var. It works fine if we use a class method for entityName instead.

I solved this for now by adding the following class method to my base class:

class func nameOfEntity() -> String {
    return ""
}

Then I added the following to machine.swift.motemplate:

override class func nameOfEntity() -> String {
    return "<$name$>"
}

When I was doing this in Objective-C, I implemented the following class method in my base class:

+ (NSString *)entityName
{
return NSStringFromClass(self);
}

This won't work in Swift, because it returns the mangled class name. I haven't found a way to return the demangled class name dynamically from Swift (Radar: 17252482).

Even if I wasn't using a base class, the current Swift templates would still fail to compile, because the method declaration would need to be prefixed by "override" if the entity is a subentity of an abstract entity. This issue will apply to other function declarations in the Swift mogenerator template in the future as it evolves.

[DaveWoodCom]

When I was looking at this last week, I was seeing lots of issues when using a base class.

I have a feeling it's going to be a bad idea to use a base class for managed objects in Swift. Because of the way Swift handles inheritance of init methods (i.e., if you include a designated init method in a subclass, none of the designated init's from the super class will be inherited). Also, the fact that you have to declare whether a subclass overrides a function (with the override keyword) based on whether the super class has it already or not, means a base class will have to conform to specific specs in order to not create conflicts with the mogenerated classes.

In Swift, we may have to avoid using a base class and instead use a protocol or something. I haven't got time right now to look into it further to confirm any of this, but will try on the weekend.

• You may want to add that radar 17252482 to http://openradar.appspot.com so we can dup it.

[grasmeyer]

Done. rdar://17252482

This would be unfortunate, since my base class implements quite a few convenience methods that I don't want to add to all of my mogenerator machine classes. One solution would be to have mogenerator automatically create a machine base class that includes the original declarations of all methods that will be overridden. Then you could add your own convenience methods to the human base class. This would require a new template, and changes to the source code. Another alternative might be to implement the convenience methods in an Extension of NSManagedObject.

[a2]

Bump

[rentzsch]

Thanks for the patch @DaveWoodCom, sorry about the delay in merging it.