on Fri May 13 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
> Sent from my iPad > >> On May 13, 2016, at 9:12 AM, Dave Abrahams <dabrah...@apple.com> wrote: >> >> >>> on Mon May 09 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote: >>> >>> My claim is that substituting the constraint of “it has value >>> semantics,” while presumably looser than the PureValue constraint, would >>> not compromise the correctness of your view controller, so not only is >>> the meaning of PureValue hard to define, but it doesn't buy you >>> anything. If you want to refute that, just show me the code. >>> >>> This is not an algorithmic use but is still perfectly valid IMO. >>> >>> If the properties of PureValue matter to your view controller, there's >>> an algorithm somewhere that depends on those properties for its >>> correctness. >>> >>> In many cases it may just be view configuration that depends on those >>> properties. I suppose you can call view configuration code an >>> algorithm but I think that would fall outside of common usage. >> >> It's an algorithm, or if the configuration is declarative, there's an >> algorithm that manipulates it. That said, I still don't have a concrete >> example of how view configuration can depend on these properties. > > The algorithm might just be "copy x bit of data to y view property, > etc". That is so trivial that it feels like a stretch to call it an > algorithm. Algorithms can be trivial. > That "algorithm" doesn't depend on this property because it executes > at a single point in time. However, a view controller might depend on > that property in order to render properly across time (for example, > configuring cells as they scroll on and off screen). The example is too abstract for me to understand. Let me put this differently: I recognize that your concept of “PureValue” may be a *sufficient* condition for some generic algorithm/component to work, but it is never a *necessary* condition, because genericity (or use of a superclass or protocol type) erases details of the actual types involved from the point of view of the algorithm/component. It doesn't matter if your type contains a class reference if it has value semantic properties. My claim is that PureValue is an overly-restrictive constraint that makes many things less useful than they should be. > This property allows us to separate values from non-local mutation and > make such separation a requirement. Rather than observing mutations > of objects with KVO, etc we might prefer to observe something that > provides a new aggregate value instead, while requiring the entire > aggregate value itself to be (observably) immutable at all times > (because we stored it with a let property locally). This can make it > easier to reason about correct behavior of your code. But it doesn't > work unless all visible parts of the aggregate are immutable. > > If you're not familiar with Elm, Redux, etc it might be worth taking > a look. That's a pretty broad link. At which parts do you think I should look? -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution