Le 17 déc. 2015 à 22:47, Kevin Ballard via swift-evolution <[email protected]> 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 [email protected] https://michelf.ca _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
