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

[Tony Allevato]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/23e4e6d7/attachment.html>