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: Peter Tomaselli <email@hidden>
- Date: Mon, 30 Nov 2015 15:05:32 -0500
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 <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