>> 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. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
