[swift-evolution] Should we rename "class" when referring to protocol conformance?
dabrahams at apple.com
Sun May 15 14:01:43 CDT 2016
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 <dabrahams at 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
>>> 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
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?
More information about the swift-evolution