> On 29 Nov 2015, at 09:26, Quincey Morris
> <[email protected]> wrote:
>
> On Nov 28, 2015, at 10:32 , Quincey Morris
> <[email protected]
> <mailto:[email protected]>> 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 protected])
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 [email protected]
