[swift-evolution] [Review] SE-0030 Property Behaviors

[plx]

> On Feb 14, 2016, at 4:15 PM, Tino Heth <2th at gmx.de> wrote:
> 
> 
>> The main shortcoming here is the complete lack of composability. I understand why behavior composition got cut, but I’m not convinced it was the right decision.
> I agree that a deliberate solution should include composition of behaviors, but I doubt that the practical value of this feature is big:
> Most likely, there won't be many different behaviors, and I expect that each of those will be small (in terms of code size). Both assumptions may be wrong in some cases, but all examples that have been discussed so far could easily be combined by simply writing a new behavior.

I think you’re half right about behaviors; there’s certainly a core group that’s going to be the most common.

The other use for behaviors is as something like a weak macro, e.g. just for views/view-controllers/etc., where there are a lot of minor things you can streamline via behaviors:

- main-queue-only
- must-be-non-nil-after-viewDidLoad
- invalidates-intrinsic-content-size
- requires-display-on-update

…and so on (I brought some of these up in the earlier discussions, just listing them again as examples).

Composability here would be nice, although not entirely necessary (e.g. using custom accessors affords a lot of room for consolidation).

> 
> This isn't elegant, but without a clear distinction between "decorating" behaviors and those that provide actual storage, many possible combinations would make no sense at all (that's no argument against composition, though)

I think you can draw a pretty nice distinction if you want; suppose that a decorator:

- *would* be able to access its container (like a behavior)
- *would not* have to deal with property storage (that’s for behaviors only)
- *perhaps* has maps sending accessor closures to closures, e.g.
  - get-decorator: (() -> T) -> (() -> T)
  - set-decorator: ((T) -> ()) -> ((T) -> ())

…which isn’t a real proposal (and e.g. doesn’t address a few major issues , like “how do we handle custom accessors (e.g. from behaviors)”), but illustrates one way one *could* make such a distinction.

> 
> Tino

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160214/524bc7fa/attachment.html>