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 <[email protected]>
Sent: Sunday, January 3, 2016 17:07
Subject: [swift-evolution] Idea: delegates as protocols and property types with
specialised behaviours.
To: swift-evolution <[email protected]>
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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
