<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 22, 2016 at 4:03 PM Michie via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div style="font-family:Arial;font-size:14px">
<p><strong>PROPOSING: Update WatchKit API Design to use properties instead of methods to set properties</strong></p>
<p>by Michie - <a href="https://github.com/michieriffic" target="_blank">https://github.com/michieriffic</a></p>
<p><br>
<strong>Introduction</strong><br>
<br>
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.<br>
<br>
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.<br>
<br>
<strong>Motivation</strong><br>
<br>
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.<br>
<br>
<strong>Proposed solution & detailed design</strong><br>
<br>
public class WKInterfaceLabel : WKInterfaceObject {<br>
<br>
public var text: String?<br>
public var textColor: UIColor?<br>
@NSCopying public var attributedText: AttributedString?<br>
<br>
}<br>
<br>
<em>INSTEAD OF</em><br>
<br>
public class WKInterfaceLabel : WKInterfaceObject {<br>
<br>
public func setText(_ text: String?)<br>
public func setTextColor(_ color: UIColor?)<br>
public func setAttributedText(_ attributtedText: AttributedString?)<br>
<br>
}<br>
<br>
<strong>Impact on existing code</strong><br>
<br>
Impact: <em>Would be more consistent and natural to the Swift language when building apps for WatchOS</em><br>
<br>
<strong>Before:</strong><br>
<br>
watchLabel.setText("Text String")<br>
watchLabel.setTextColor(UIColor.red())</p>
<p><strong>After:</strong><br>
<br>
watchLabel.text = "Text String"<br>
watchLabel.textColor = UIColor.red()</p>
<p>Will some Swift applications stop compiling due to this change? <em>Possible</em><br>
<br>
Will applications still compile but produce different behavior than they used to? <em>No, if everything was migrated properly.</em><br>
<br>
Is it possible to migrate existing Swift code to use a new feature or API automatically? <em>Yes.</em><br>
<br>
<strong>Alternatives considered</strong><br>
<br>
Just use what's currently available.</p>
</div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>