<div dir="ltr">I really like the idea of having a 'protocol initializer' which transparently chooses an appropriate concrete type to return. Once recursive protocol conformance and conditional conformance has been implemented, you'd be able to work with type "aggregates" (imagine JSON or plist types implemented exclusively as protocol conformances on existing types) almost completely in terms of the generic protocol interface.<div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 3:24 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Throughout its frameworks, Apple makes use of the “class cluster” pattern as a means to separate the public API out from the (potentially complex) internal representations of the data. Clients of the API simply use the public API, while under the hood a different implementation is chosen to most efficiently represent the provided initialization parameter values.<br>
><br>
> Unfortunately, because initializers in Swift are not methods like in Objective-C, there is no way to specify what the actual return value should be (short of returning nil for failable initializers). This makes it *impossible* to actually implement the class cluster pattern in Swift.<br>
<br>
</span>I’d actually like to put Objective-C interop aside for a moment. There are many class clusters in Objective-C, but most of them are things you rarely need to subclass yourself. When was the last time you wrote an NSArray subclass? What’s more interesting to me is how we can provide a similar native Swift pattern.<br>
<br>
Here’s my thinking.<br>
<br>
First of all, we call them “class” clusters, but there’s no reason this should be only for classes. A “class cluster” is basically a single API which offers access to many different implementations of an interface. The phrase “many different implementations of an interface” is a hint that we should be thinking about protocols.<br>
<br>
Here’s what I think Swift should support:<br>
<br>
protocol HTTPParameterListType {<br>
var all: DictionaryLiteral<String, Strong> { get }<br>
subscript (name: String) -> [String] { get }<br>
}<br>
<br>
// Various implementations include:<br>
struct JSONParameterList: HTTPParameterList {...}<br>
struct MultipartParameterList: HTTParameterList {…}<br>
struct URLEncodedFormParameterList: HTTPParameterList {…}<br>
struct QueryParameterList: HTTPParameterList {…}<br>
<br>
extension HTTPParameterListType {<br>
protocol init(request: NSHTTPRequest, bodyData: NSData) throws {<br>
switch request.valueForHTTPHeaderField(“Content-Type”).map({ MIMEType(rawValue: $0) }) {<br>
case .JSON?:<br>
return try JSONParameterList(data: bodyData)<br>
<br>
case .MultipartFormData?:<br>
return try MultipartParameterList(data: bodyData)<br>
<br>
case .URLEncodedForm?:<br>
return try URLEncodedFormParameterList(data: bodyData)<br>
<br>
default:<br>
return try QueryParameterList(request: request)<br>
}<br>
}<br>
}<br>
<br>
// Usage:<br>
self.parameters = HTTPParameterListType(request: request, bodyData: data)<br>
<br>
A `protocol init` in a protocol extension creates an initializer which is *not* applied to types conforming to the protocol. Instead, it is actually an initializer on the protocol itself. `self` is the protocol metatype, not an instance of anything. The provided implementation should `return` an instance conforming to (and implicitly casted to) the protocol. Just like any other initializer, a `protocol init` can be failable or throwing.<br>
<br>
Unlike other initializers, Swift usually won’t be able to tell at compile time which concrete type will be returned by a protocol init(), reducing opportunities to statically bind methods and perform other optimization tricks. Frankly, though, that’s just the cost of doing business. If you want to select a type dynamically, you’re going to lose the ability to aggressively optimize calls to the resulting instance.<br>
<br>
Perhaps this feature can then be extended back to classes, with a `class init` being an un-inherited initializer which uses `return` to give the caller a new object. `self` would be the class object, and only class variables and methods would be callable from it. But like I said, I’m not particularly interested in Objective-C interop right now.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>