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

Activity

1. qmathe

   added

   API

   core

   metamodel

   cleaning

   on Sep 19, 2016
2. ericwa commented on Sep 20, 2016

   

   ericwa

   on Sep 20, 2016

   Member

   More actions

   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?
3. qmathe commented on Sep 20, 2016

   

   qmathe

   on Sep 20, 2016

   Last edited by qmathe

   MemberAuthor

   More actions

   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.
4. qmathe commented on Sep 20, 2016

   

   qmathe

   on Sep 20, 2016

   MemberAuthor

   More actions

   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.