Very much so for some of us... ;)
No, but coming from Objective-C if I have an integer or a point, then I view those as primitive types. But if my view had some richer object, like a Person, then I would expect to be able to edit those properties. If the Person was a class, which it would likely be in Objective-C, then every other view with a reference to that Person would see the changes.
(Admittedly, that's a problem unto itself and something value types try and prevent.)
I agree. Trying to use value types from top-to-bottom is the goal but that's where I'm hitting some walls. Inevitably, some classes start popping up and kind of break the implementation.
I'm playing a little loose with my terminology, but you're right. When I think of having a "reference" to something when discussing a type like a Tree, what I'm really thinking of is the reference to the Array's underlying shared storage.
So while I do have a copy, my copy does have a reference under the hood. This has tripped me up in the past when benchmarking some code and wondering why a seemingly simple mutation, like toggling a boolean property, was so slow. Turns out a copy I had made of a property was triggering CoW, but the performance degradation was only noticed when mutation occurred, now when the copy occurred. I completely understand why, but in my (very) early days of learning Swift it caught me off guard.
Point being, if I do have an extensive data structure that is getting mutated, it's important that nobody else have a copy of it if performance is important. That means checking if any views or intermediate components happen to be making a copy purely for convenience, or perhaps bad habits.
In some ways, that's the answer I'm trying to determine. When looking at functional languages and functional frameworks, value semantics, or immutable data, make a lot of sense and it's relatively clear how to program within those constraints.
When dealing with pure Swift, I think that's also the case. But when using Swift within the context of an AppKit or UIKit application, where I'm sure the vast majority of Swift is used, then for me at least it gets a lot harder to reason about.
It might very well be that these older frameworks are not entirely compatible with pure value semantics, which is fine. But I've been curious if my difficulties are because of this or that I'm just "doing things wrong".
This is sort of the approach I've been playing with. A sort of "view model", which is a class, owns the data which is represent as a value type. How to "address" things and make the mutations is what started this thread for me.
You're right. As noted above, what I was trying to say was that a copy of a Tree also has a copy of rootNodes: Array. Each copy of that Array does have a reference to the shared, underlying storage.
Thus, two views, each with their own copy of the Tree, indirectly also have a reference to the underlying storage. That's where I'm (incorrectly?) applying the word "reference".
– Appreciate all the input and lengthy replies.