> On Dec 21, 2015, at 5:22 PM, Brent Royal-Gordon <[email protected]> > wrote: > >>> I actually think that behavior instances should probably be private, and >>> there should be no way to change that. Behaviors are inherently an >>> implementation detail, and you should not be exposing them directly to >>> users of your type. Instead, you should expose just the operations you >>> expect to be needed through your own calls, which you can reimplement as >>> needed. >> >> I'm leaning in this direction too. The idea of exposing the behavior itself >> as a value seems wrong for almost any client. "foo.prop.reset()" is slightly >> nicer than "foo.resetProp()", but not if it conflicts with a 'reset' that's >> already on the property type. "[email protected]()" certainly isn't an >> improvement. > > I've been thinking about this more, and I think there's at least one > exception: if you introduce a behavior that allows for arbitrary observers to > watch a property (basically a KVO replacement), you want a standard way to > access that functionality, rather than having to declare cover methods for > everything. So maybe the visibility of the behavior should be controllable, > but by the behavior itself, not the property it's applied to.
Yeah. There are behaviors where exporting the functionality is important, so I think we need to preserve the ability to make them public. In addition to `KVOable`, `resettable` also meets this criterion—there's no point in declaring a resettable property if clients can't reset it. Maybe visibility is a trait of the behavior, though, and not necessarily of the property declarations using it, since something like 'KVOable' is almost always something you want to publish, whereas `lazy` is almost always an implementation detail. However, I could see people wanting to also publish things like `lazy`, `copying`, or `synchronized` as documentation of semantics, even if they aren't directly useful as API. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
