[swift-evolution] [Proposal] Property behaviors

[Wallacy]

Few questions:

1 - This model has any optimization opportunities in mind? Like allow the
compiler optimize calls over behaviors?

2 - Will be possible compose behaviors and resuse, like:
typealias lazyObserver = [lazy,observer]

3 - "var behavior" will make unusual create any other property called
behavior. Its not better make behavior a reserved word like "protocol" and
use then? protocol is also a valid identifier.

4 - Will be provided any implementation of standard library of any other
behavior like "lazy", "observer"?

5 - How to handle with behavior name collision? If two modules define the
same behavior name, can be handled using full name (module.behavior)?

Em sáb, 16 de jan de 2016 às 17:27, Joe Groff via swift-evolution <
swift-evolution at swift.org> escreveu:

>
> On Jan 15, 2016, at 5:54 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>
> On Jan 15, 2016, at 7:45 PM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Jan 15, 2016, at 6:42 AM, plx via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> One more “how will this work?” question: optionals.
>
> Specifically, consider something like this:
>
> // annoyingly-long protocol:
> protocol ControlExchanging {
>   typealias Context
>   func willTakeControlFrom(other: Self?, context: Context)
>   func didTakeControlFrom(other: Self?, context: Context)
>
>   func takeControl(context: Context)
>   func cedeControl(context: Context)
>
>   func willCedeControlTo(other: Self?, context: Context)
>   func didCedeControlTo(other: Self?, context: Context)
> }
>
> var behavior exchangeState<Value:ControlExchanging where
> Self:Value.Context> : Value {
>   var value: Value
>   // here:
>   set {
>     let oldValue = value
>     // boilerplate-choreography begins:
>     newValue.willTakeControlFrom(oldValue, context: self)
>     oldValue.willCedeControlTo(newValue, context: self)
>     oldValue.cedeControl(self)
>     value = newValue
>     newValue.takeControl(self)
>     oldValue.didCedeControlTo(newValue, context: self)
>     newValue.didTakeControlFrom(oldValue, context: self)
>   }
> }
>
> // numerous extraneous details omitted:
> class GenericSwitchboard<Delegate:ControlExchanging were Delegate.Context
> == Self> {
>
>   private(set) weak var [exchangeControl] delegate: Delegate? = nil
>
> }
>
> …which presumably won’t actually work unless I’ve either:
>
> - added an additional implementation that’s typed-as `Value?`
> - added a conditional-conformance for `ControlExchanging` to `Optional`
> (easy, but boilerplate)
>
> ….both of which are workable, neither of which feels optimal (and for the
> latter, consider also that in many cases such conformances may generally be
> undesirable).
>
> Is there a trick/detail I’m missing here?
>
>
> No, I think you've got it. This seems like a general problem to me,
> though; it'd be nice if protocol conformances could be easily forwarded,
> for instance from Optional<T> to T.
>
>
> Any thoughts about how that might work when requirements have a return
> value?  Or are you just referring to forwarding conformances when the
> protocol doesn’t have members  with return values?
>
>
> I don't have a great answer in mind, unfortunately. You're right that it
> only really makes sense for "sink"-like protocols, where none of the
> requirements produce a value, or theoretically for protocols where all
> results are of associated types that could be optionalized. The sink
> protocol use case comes up all the time, though, especially with delegates
> and callbacks, and is one the places where ObjC's nil-messaging behavior
> feels legitimate.
>
> -Joe
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160118/37d5a2f2/attachment-0001.html>