Idea: delegates as protocols and property types with specialised behaviours.


(Ross O'Brien) #1

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


(Alex Popov) #2

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@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@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