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 <vast.gra...@gmail.com> 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 <r...@rols.org
> <mailto: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
