Rename COObject.isPersistent/Shared to COObject.persistent/shared

[qmathe]

For consistency with Swift and Objective-C style guide, properties COObject.isPersistent and COObject.isShared should be declared like that:

@property (nonatomic, getter=isPersistent, readonly) BOOL persistent;
@property (nonatomic, getter=isShared, readonly) BOOL shared;

This requires to change CoreObject metamodel and create a schema migration.

[ericwa]

just curious, when writing code to access such a property, you're supposed to write obj.isPersistent, right? This is what https://swift.org/documentation/api-design-guidelines/ says (search for "boolean").

So the form without the is prefix is only used for reflection / serialization?

[qmathe]

Yes that's the idea, but it's a bit more complex than that, since ObjC and Swift don't use the same exact rules and Swift rules have been completely overhauled between Swift 2.2 and Swift 3.

Apple usually declares an empty property like that in ObjC: @property (nonatomic, readonly, getter=isEmpty) BOOL empty;

For Swift 2, the API translation is: var empty: Bool

For Swift 3, this has been changed to: var isEmpty: Bool

In ObjC, both something.isEmpty and something.empty are valid ways to access the property. In Swift, you can only use a single syntax, which is the one used to declare the property.

I think the motivation behind the change is to make a clear distinction between two API kinds without relying on type overloading, or mapping one API kind to property and the other to function:

• lazy, empty, capitalized --> return a new value
• isLazy, isEmpty, isCapitalized -->return a boolean and are used to query the receiver

Usually Swift 3, will declare lazy, capitalized, sorted etc. as functions and not properties. There are some exceptions which look like mistakes to be corrected in the future imo. For instance, this looks inconsistent:

var capitalized: String
func capitalized(with:) -> String

This looks consistent:

func lowercased() -> String
func lowercased(with:) -> String

For comparing Swift APIs, check: http://swiftdoc.org

In the end, it's a bit messy, because if we declare COObject.shared with isShared as getter as Apple does it in ObjC, then the property appears as shared in the metamodel… but if we later rewrite COObject code with Swift, the property might have to be changed back to isShared in the metamodel. I say might have because there is almost no reflection in Swift currently, so may be the upcoming Swift 4 reflection API will be able to cope with these sort of issues.

[qmathe]

Before making any changes, we should probably send a mail to the Swift evolution list asking what are the plans on this front, or what they suggest to cope with this issue.