On Tue, Sep 19, 2017 at 11:52 PM, Benjamin Garrigues via swift-evolution <swift-evolution@swift.org> wrote:
Seeing this proposal for the first time and the previous messages in that
thread makes me wonder : is making extensive use of getters and setters an
encouraged coding style in swift ?
In every language that has them, i tend to keep their use to the strict
minimum, because i find that
1/ properties that begin too need complex behaviors upon being set or read
always end up needing additional parameters and so need to be accessed
through functions.
2/ using them too much makes the code end up like a soup of state and
behaviors affecting that state, whereas i like to structure my code in (at
least) two distinct section with data on one side and effects on another.
Sorry if all this has been already discussed multiple times before, i'm only
following this list for a few weeks.
Le 19 sept. 2017 à 22:56, Hooman Mehr via swift-evolution > <swift-evolution@swift.org> a écrit :
These types of unusual property behaviors could be implemented if we had
property behaviors proposal revised and implemented. How about resurrecting
this for Swift 5.x? I think it will also be a useful feature that can help
in the implementation of the concurrency model. To clarify the relation to
concurrency: Will actors support public properties? What would a getter for
such a property do? It is a similar asymmetric get/set issue, because an
actor property may end up being set-only which is impossible in the current
Swift property model.
On Sep 19, 2017, at 1:36 PM, Philippe Hausler via swift-evolution > <swift-evolution@swift.org> wrote:
There is another case to consider; similar to nil-resettable. Optional only
by virtue of never being set, but setting nil values is invalid (e.g.
Process.environment)
On Sep 19, 2017, at 9:34 AM, Tony Allevato via swift-evolution > <swift-evolution@swift.org> wrote:
There have been a couple times where I've wanted something like this:
1) A nil-resettable property without having to resort to making it an IUO.
It would be nice to have the setter able to take a T? but the getter return
T, and the setter would provide a default value in the event that it
receives nil.
2) Once I was writing an API that would keep an array of things in a
property, but I also wanted a shorthand version where the user could set it
with a single value and have the setter transform that into the array
internally. Looking back though, that's not really defensible; it's easy
enough for the call site to just add two characters and write "foo.property
= ", and I probably wouldn't stand by that example today.
On Tue, Sep 19, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution > <swift-evolution@swift.org> wrote:
This may sound rather strange in the abstract, but recently I have
encountered two situations where I would like to have a setter that accepts
a different type than the getter returns.
In the first, the getter returns Foo and the setter should accept
“@escaping @autoclosure () -> Foo”, so that the expression assigned to the
property is not evaluated until it is needed. (The closure is stored in a
private property, which the getter evaluates then caches the result.)
In the second, I want a subscript whose getter returns a concrete type (in
my case, subscripting a matrix by row returns an ArraySlice<Element>) while
the setter can accept something more generic (any kind of Collection with
the correct Element type).
Thoughts?
Nevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution