I have no answer here, but there is a blog post I continually refer to whenever I get confused about this. In case you haven't already read it (although I suspect you have) it is called "Swift: Associated Types" by Russ Bishop [0]. Rob Napier has also had a few nice posts about type erasure that may be relevant.
I'm a C# dev by day and my first pass at your problem would probably be quite similar to what you have already, in that the first instinct is to let all the generic parameters bubble up to the top and trust in your ability to pivot where you need to go from there. What Russ does a good job of explaining in that post is that Swift protocols are not really "just [C# or Java] interfaces" in this way. Again, apologies if this is obvious stuff but it probably will be interesting to someone on the list. Just spitballing here, but it seems like two aspects of your approach here might be at odds: one, you want a "strongly typed" TimeSeries collection of some kind, but you also want some degree of implementation hiding, right (I base this on your desire to be able to just plop one of these into a tableView and have it work)? To me that feels like you actually don't want to include a typealias in your protocol (adopters of the protocol could of course still be generic), and that the truth is that the view actually doesn't care about the underlying type in the collection. Instead, contractually, all it cares about is that TimeSeries can be a dataSource (basically, that it can vend strings for a given indexPath). Perhaps what you want are two protocols, one that enforces whether or not a collection is easily "presentable", and one that enforces that a collection has some TimeSeries-ish "semantics" (whatever that might mean). Your actual classes here could conform to both, but the view only need care about the first one. If you actually do want _both_ of those things together, that's where (and I could be way off here; I have only casually read up on this stuff) techniques of "type erasure" may be relevant? Peter [0] http://www.russbishop.net/swift-associated-types On Mon, Nov 30, 2015 at 7:12 AM, Roland King <r...@rols.org> wrote: > I keep running myself into this issue when I try using some of my generic > classes built on top of Protocols. > > [snip] > > There’s still no clever way around this right, this is still how Generics > and Protocols work together, there’s nothing in Swift 2.0 which helps you > work around this, no way to use Protocol extensions to do it? I thought > (I’ve tried this before) of making a FloatTimeSeries protocol which only > deals with Floats and has no Self or associated type issues which basically > has all the same methods of TimeSeries but with ‘Float’ specifically > instead of Underlying and then using a protocol extension like this > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
