[swift-evolution] Idea: delegates as protocols and property types with specialised behaviours.

[Alex Popov]

I don't think this is necessary, but if it does go through, I would prefer the `?` be optional, as occasionally I make my delegates `unowned` so that I don't have to do a bunch of nil handling/coalescing in the case where the delegate strictly owns the other object and both will be deallocated together.The stack and multiple declarations are interesting, but if Swift 3 brings us the generics we need, those should be possible to implement without adding new keywords/complexity to the language.Alex Popov Jr.
Principal iOS developer | Shelfie


    _____________________________
From: Ross O'Brien via swift-evolution <swift-evolution at swift.org>
Sent: Sunday, January 3, 2016 17:07
Subject: [swift-evolution] Idea: delegates as protocols and property types with specialised behaviours.
To: swift-evolution <swift-evolution at swift.org>


           At the moment, the delegate pattern is just one use of protocols. We create a protocol with a set of declared functions, implemented either in a protocol extension or in the conforming type - the delegate - and another type calls functions of its delegate, notifying them when certain events occur.    
          
          I'm wondering if uses of the delegate pattern can or should be made more explicitly readable. The form I have in mind creates a keyword 'delegate', which is used in two contexts; one to replace 'protocol' in the declaration of a protocol intended as a delegate, and one to declare a property of the delegate type.          
          So, for example:          delegate UITableViewDataSource { }          
          and          class UITableView          {              delegate dataSource : UITableViewDataSource              delegate delegate : UITableViewDelegate          }          
          (I realise this example uses 'delegate' both as a keyword and a property name, and would cause a lot of rewriting for types which generically refer to their delegates with the property name 'delegate', so perhaps this isn't the best choice of keyword, but bear with me, the idea may still have merit.)          
          As a term for declaring a property, 'delegate' could be synonymous with 'weak var', and the type would be implicitly a non-force-unwrapped optional. I can't presently think of a type in Objective C or Swift which requires a strong reference to its delegate. (It might be preferred that the "?" remain explicit for readability).          
          Here are two suggestions from where delegates could benefit from being distinct types.          
          First: if the delegate pattern is observational (i.e. the type with a delegate property calls its delegate's functions as notifications), then there can be a need for multiple observers (e.g. multiple services in an app being notified that location services have been started).          (I've tried implementing something like this; an array of references to observer-type delegates at the moment maintains strong references to all delegates, so I've created a custom struct with a weak reference to the specific protocol's type and called 'forEach' on a sequence of such structs; if the reference is nil, the struct can be removed from the sequence. Much as I'd like this struct to be generic, I don't think I can create a generic struct with a protocol as the associated type.)          This might be declared with a keyword in the same way properties are modified with lazy / weak:          multiple delegate : CLLocationManagerDelegate?          
          Second: the delegate pattern, if applied to a group of delegates, might not be strictly observational, but might also respond in some way - a sequence of delegates could be called in turn, with candidates being asked if they can respond, returning false if they can't, true if they can.          
          Third: delegates could also form a stack. For example, in an NSXMLParser, the parser's delegate can change during parsing, as types handle their 'layer' of parsing and then pass control to child or parent parser-delegate types. This could be simplified to calling something akin to: 'parser.delegate.push(childType)' or 'parser.delegate.pop()'          This might be declared like this:          stack delegate : NSXMLParserDelegate?          
          I may be combining too many ideas into one proposal, or there may be more ideas others can add. Is this worthy of discussion?          
          -- Ross O'Brien          


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160104/8c467a46/attachment.html>