[swift-evolution] [Proposal] Property behaviors

[Michel Fortin]

Le 17 déc. 2015 à 22:47, Kevin Ballard via swift-evolution <swift-evolution at swift.org> a écrit :

> Good point. I'm also inclined to say that Michel's motivating example (of a property that requires going through a `synchronized` accessor) would be better modeled just as a type Synchronized<Value> that exposes the `synchronized` accessor. No need for behaviors, you just say
> 
> var data: Synchronized<T> = ...
> 
> Behaviors are interesting because they affect how normal property access works. Properties that don't expose normal property accessors aren't really properties at all.

> 

> The only real downside to the Synchronized<Value> type is there's no way to prevent anyone from copying the value (it could be a class, but then you're paying for the overhead of using a separate object). This same limitation is also one of the problems with adding an Atomic<T> type, which is something I would dearly love to have.


There's indeed the problem that you can't disallow copying a value, and that makes anything involving a mutex a bit fragile. Even if you append a mutex to a property through a behaviour, can a struct containing that property be safely copied? Or should that behaviour be reserved for properties in classes?

And then the question about the definition of a "property"? Is it still a property if the getter is inaccessible? Maybe not. But this thread is all about redefining properties.

The reason I'm suggesting implementing synchronized as a behaviour instead of a type is because I found out with experience that synchronization should be related to variables, not types. Types exists in a vacuum while variables are bound to a context, and a synchronized access pattern should usually stay encapsulated in a particular context (struct or class). A Synchronized<T> should not be copied or passed by reference and used out of its context; a property behaviour makes that just impossible, which is better.

If it turns out it does not work with the final design of behaviours, it won't be too bad I guess. But I think it'd be a better fit as a behaviour than as a type.


-- 
Michel Fortin
michel.fortin at michelf.ca
https://michelf.ca