[PITCH] WatchKit API Design Change to use properties instead of methods to set properties

Evolution Pitches
1

PROPOSING: UPDATE WATCHKIT API DESIGN TO USE PROPERTIES INSTEAD OF METHODS
TO SET PROPERTIES

  by Michie - michieriffic · GitHub

INTRODUCTION

WKInterfaceLabel is still using methods for set Text (setText), set Text
Color (setTextColor), set Attributed Text (setAttributedText) to set
properties of WKInterfaceLabel. I think it's more appropriate to make these
into properties rather than methods just like in the UILabel. That would
make it more consistent with building apps for both iOS, MacOS, WatchOS,
and more.

Also, other objects in WatchKit needs to be updated too to use properties
instead of methods to set properties so we can easily access it using dot
notation. WKInterfaceLabel is just an example.

MOTIVATION

While creating an app for watchOS, it has been a habit for me to use the
dot notation to access a property of an object and set it using "=". And
text, textColor, and attributedText are properties rather than methods of
an object.

PROPOSED SOLUTION & DETAILED DESIGN

public class WKInterfaceLabel : WKInterfaceObject {

public var text: String?
public var textColor: UIColor?
@NSCopying public var attributedText: AttributedString?

}

/INSTEAD OF/

public class WKInterfaceLabel : WKInterfaceObject {

public func setText(_ text: String?)
public func setTextColor(_ color: UIColor?)
public func setAttributedText(_ attributtedText: AttributedString?)

}

IMPACT ON EXISTING CODE

Impact: /Would be more consistent and natural to the Swift language when
building apps for WatchOS/

BEFORE:

watchLabel.setText("Text String")
watchLabel.setTextColor(UIColor.red())

  AFTER:

watchLabel.text = "Text String"
watchLabel.textColor = UIColor.red()

  Will some Swift applications stop compiling due to this change? /Possible/

Will applications still compile but produce different behavior than they
used to? /No, if everything was migrated properly./

Is it possible to migrate existing Swift code to use a new feature or API
automatically? /Yes./

ALTERNATIVES CONSIDERED

Just use what's currently available.

2

PROPOSING: Update WatchKit API Design to use properties instead of methods to set properties

swift-evolution does not control how specific Apple frameworks, like WatchKit, get exposed to Swift. We sometimes review proposals from framework teams like Apple and LibDispatch on how they want to expose their APIs, but the details are still up to them. If you want to influence the design of Apple frameworks, the best way to do that is still Radar <https://bugreport.apple.com>.

As for your specific proposal, the main problem I see with this is that these WatchKit classes offer only setters, not getters, and Swift doesn't support setter-only properties. Adding that support would not be very compatible with value types, because we need to be able to access the existing value in order to mutate it. I have nothing to do with the development of WatchKit, so I'm speculating, but I believe this design was chosen so that user interface updates could be asynchronous. Currently, nothing I can think of in WatchKit ever uses a return value; supporting getters in these APIs would run counter to that goal.

···

--
Brent Royal-Gordon
Architechies

3

We sometimes review proposals from framework teams like Apple and LibDispatch

Sorry, that should have been "Foundation and LibDispatch".

···

--
Brent Royal-Gordon
Architechies

4

Doing this would require a larger change in Swift than a single API.
WKInterfaceLabel is "one-way" in the sense that those values can be set
with setter methods, but there is no API to get the values back. This can't
map to properties in Swift as they're implemented today, because a property
with a custom setter must also have a custom getter.

That being said, a property is intended to be something that *can* be read
and used elsewhere in expressions, like a variable, so such a change
wouldn't (in my opinion) be warranted. The fact that the setting is through
an explicit set* method instead of a property makes it stand out to the
user as something that doesn't function like a regular property does.

···

On Wed, Jun 22, 2016 at 4:03 PM Michie via swift-evolution < swift-evolution@swift.org> wrote:

*PROPOSING: Update WatchKit API Design to use properties instead of
methods to set properties*

by Michie - https://github.com/michieriffic

*Introduction*

WKInterfaceLabel is still using methods for set Text (setText), set Text
Color (setTextColor), set Attributed Text (setAttributedText) to set
properties of WKInterfaceLabel. I think it's more appropriate to make these
into properties rather than methods just like in the UILabel. That would
make it more consistent with building apps for both iOS, MacOS, WatchOS,
and more.

Also, other objects in WatchKit needs to be updated too to use properties
instead of methods to set properties so we can easily access it using dot
notation. WKInterfaceLabel is just an example.

*Motivation*

While creating an app for watchOS, it has been a habit for me to use the
dot notation to access a property of an object and set it using "=". And
text, textColor, and attributedText are properties rather than methods of
an object.

*Proposed solution & detailed design*

public class WKInterfaceLabel : WKInterfaceObject {

   public var text: String?
   public var textColor: UIColor?
   @NSCopying public var attributedText: AttributedString?

}

*INSTEAD OF*

public class WKInterfaceLabel : WKInterfaceObject {

   public func setText(_ text: String?)
   public func setTextColor(_ color: UIColor?)
   public func setAttributedText(_ attributtedText: AttributedString?)

}

*Impact on existing code*

Impact: *Would be more consistent and natural to the Swift language when
building apps for WatchOS*

*Before:*

  watchLabel.setText("Text String")
  watchLabel.setTextColor(UIColor.red())

*After:*

  watchLabel.text = "Text String"
  watchLabel.textColor = UIColor.red()

Will some Swift applications stop compiling due to this change? *Possible*

Will applications still compile but produce different behavior than they
used to? *No, if everything was migrated properly.*

Is it possible to migrate existing Swift code to use a new feature or API
automatically? *Yes.*

*Alternatives considered*

Just use what's currently available.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution