Re: swift - making array of subclass of class also conforming to protocol
Re: swift - making array of subclass of class also conforming to protocol
- Subject: Re: swift - making array of subclass of class also conforming to protocol
- From: Roland King <email@hidden>
- Date: Sun, 29 Nov 2015 09:53:56 +0800
> On 29 Nov 2015, at 09:26, Quincey Morris <email@hidden> wrote:
>
> On Nov 28, 2015, at 10:32 , Quincey Morris <email@hidden <mailto:email@hidden>> wrote:
>>
>> It can’t be UIView+MasterControllable (in some syntax), because no such *single* type exists.
>
> One other dopey alternative occurred to me. You could add all the methods from UIView, or just those your app actually uses, directly to the MasterControllable protocol. Your conforming subclasses will of course inherit conformity to these requirements from the real UIView, so there’s no extra work or runtime overhead. If the UIView API ever changes, then you’ll conformance errors in your subclasses the next time you compile.
>
> There are probably hundreds of methods in UIView, but chances are you’ll only need a couple of dozen to be exposed in the enlarged MasterController.
>
> FWIW
>
Thanks - I was just writing a reply to your last message which said I’d tried containment but it made the rest of the code clunky and so, realising I only need about 4-5 methods from UIView I made a UIViewProtocol protocol with those methods in and ‘extended’ UIView to conform to it. At the same time I did add another read-only property into that protocol which returns a UIView, a real one, which the extension trivially implements with
var view : UIView { return self }
And then I can make an array<protocol<UIViewProtocol,MasterControllable>> and I have pretty close to what I want.
When I’m calling methods *on* the view, they’re in the protocol so I can call them directly, if I need to use the object *as* a UIView, to send it to something else, like addSubview(), then I have to stick the ‘.view’ on the end, which isn’t a terrible hardship. So it looks a bit like containment in some cases, and like extension in most of them, not a horrid hybrid.
Were UIView written as a protocol and a single implementing class, this would be pretty easy, I wonder as Swift develops whether more of the library will be adjusted to be that way. Perhaps UIView would be the last thing to get there but you an see how having many classes as just implementing various Cocoa/UIKit protocols would be a useful recasting.
That also possibly suggests an answer to your question in the previous mail, ‘what would class<SomeClass,SomeProtocol> mean’? How about, and I’m sure there are some big gaping holes in this, if a class counted as an object implementing a protocol of the same-named-type, so protocol<UIView,SomeProtocol> would mean a protocol which has all the methods of UIView and all the methods of SomeProtocol and could be used wherever a UIView class/subclass was used. That would be an interesting trick for moving to protocol-based programming.
Anyway this is rigorous enough for what I’m doing, I just wanted to avoid too many ‘as?’ constructs which to my mind give the code a bit of an odour.
_______________________________________________
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