Re: Self and associated type requirements (yes again!)
Re: Self and associated type requirements (yes again!)
- Subject: Re: Self and associated type requirements (yes again!)
- From: Roland King <email@hidden>
- Date: Tue, 01 Dec 2015 09:32:03 +0800
I hadn’t actually read that blog post, I’ve read lots, but not that one - so thanks for the link. Any blog post who’s first paragraph ends with ‘I want to tie you up in a sack, throw the sack in a river, and hurl the river into space’ is probably worth reading, so I’m reading it.
I think I am stuck with it in this case because of my inability to get over myself and make TimeSeries a thing which returns Floats. If I did that, all my problems would go away (possibly not actually - see the end of my last diatribe about Generators, I’d probably also need to get over myself and not make TimeSeries a SequenceType but something which returned a thing which returned something concrete). But I never found a wall I didn’t like bashing my head against so I’ll continue. I can split some behaviour into another protocol, I have actually, but the basic fact that TimeSeries is a protocol and it’s a series of anything-you-can-think-of means at some point I have to use a concrete class to specify which implementation of it I actually am going to use so the compiler can actually compile it.
Before the end of today I’m fairly sure my code will look like this
public struct TimeSeriesView : UIView
{
public let series : CompressedTimeSeries<Float>
}
because the CompressedTimeSeries implementation ends up being better, faster, saves memory and can employ some useful drawing optimisations. It would also mean I can stop flagellating and get back to solving the problem I was writing the code for in the first place, which was building a reflow oven. Anyone who’s heard the old saying about draining swamps and alligators knows where I am right now.
But I’ll read the article first.
> On 1 Dec 2015, at 04:05, Peter Tomaselli <email@hidden> wrote:
>
> 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 <http://www.russbishop.net/swift-associated-types>
>
> On Mon, Nov 30, 2015 at 7:12 AM, Roland King <email@hidden <mailto:email@hidden>> 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 (email@hidden)
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:
This email sent to email@hidden