[swift-users] Are value semantics really appropriate in a diagramming app?

[Jordan Rose]

I happen to agree with Jens, though Dave Abrahams (and Crusty) might disagree with me. The number one consideration for choosing between a value type and a reference type is “do I want value semantics or reference semantics?” If I want to talk about a particular shape, talk about “that one”, I can only do that if there’s some notion of identity. So yes, if that’s part of my app, I would start with reference types.

Now, that doesn’t have to apply to rendering. As shown in the presentation, if you’re generating the shapes, there’s no need to refer to a particular shape afterwards…especially if the shapes are immutable. Any individual shape is just data to be rendered. But if I want a command like “change the color of that square”, then I need a way to know what “that square” refers to, and an object with persistent identity—a class instance—is one way to do it.

You can get a notion of “identity” in ways other than reference semantics—say, by generating unique IDs that go with a particular shape, and then looking them up later. But it’s a perfectly fine choice to make your model use reference semantics.

All of that said, reference semantics do have traps: mutation makes things harder to test in isolation, and mutation with shared state makes things not thread-safe. So you have to decide what trade-off you want to make in your app.

Jordan


> On Aug 1, 2016, at 19:18, Jack Lawrence via swift-users <swift-users at swift.org> wrote:
> 
> Jens: Why? There are significant benefits to value semantics for this type of problem, for the reasons laid out in the WWDC videos. It would be helpful to know why you disagree in this case—maybe there are solutions to the issues you’re thinking of.
> 
> Rick: I’d think that value semantics would be the right choice here. When you do a mutation, you would copy the state of the entire diagram. It should be efficient via COW, but if not you can implement you own more fine-grained COW types with isUniquelyReferenced(). This would allow you to easily support things like undo.
> 
> Jack
>> On Aug 1, 2016, at 4:32 PM, Jens Alfke via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>> 
>> 
>>> On Aug 1, 2016, at 1:19 AM, Rick Mann via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>> 
>>> It seems like reference semantics are more appropriate here.
>> 
>> Yes, they are. (Just because structs exist doesn’t mean you have to use them everywhere.)
>> 
>> —Jens
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org <mailto:swift-users at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160801/74eee36a/attachment.html>