[swift-evolution] Either protocol syntax
Matthew Johnson
matthew at anandabits.com
Thu Feb 2 16:10:11 CST 2017
> On Feb 2, 2017, at 4:02 PM, Rex Fenley <rex at remind101.com> wrote:
>
> But then any time as user of the pipeline I'm writing would like a new type of collection they will be forced to inherit this new protocol vs one they're already familiar with and which the collection may already conform too.
Yes, that is true. But if you design your new protocol such that it’s requirements all match a requirement in `RangeReplaceableCollection` then conformance will be a one-line extension. This may not be ideal, but it’s really not too bad and you can do it today.
>
> On Thu, Feb 2, 2017 at 1:53 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>
>> On Feb 2, 2017, at 3:46 PM, Rex Fenley <rex at remind101.com <mailto:rex at remind101.com>> wrote:
>>
>> My use case is RLMArray and it can't implement RangeReplaceableCollection though because `init` is unavailable, additionally, there's a lot of parts to the protocol that would take some time to implement correctly if I could. They offer a Swift type List that wraps RLMArray and does a bunch of stuff to implement RangeReplaceableCollection, but they discourage using their Swift library in mixed Obj-C/Swift projects and certain model objects simply couldn't use the List type anyway because they're also used in Obj-C and List is not @objc compliant.
>>
>> So this leaves me in situations where when I need to use Array or RLMArray I have to duplicate my code, not just in one place, but all the way down a pipeline in order to have my generics work with either RangeReplaceableCollection or RLMArray.
>>
>> If I could abstract the commonalities required by my application, I could just have a RLMArrayProtocol that has RLMArray's exposed function signatures and a new protocol Appendable = RangeReplaceableCollection | RLMArrayProtocol and this will type check all the way through the pipeline.
>>
>> tl;dr - if a function signature required by a protocol is marked unavailable on a class, then disjunction is necessary in order to bridge the two (or more) types without duplicating code.
>
> You should be able to solve this problem today by creating a custom protocol that you use as a constraint in your generic code and providing conformances for both Array and RLMArray.
>
>>
>> On Thu, Feb 2, 2017 at 1:35 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>>
>>> On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> Hello, I believe there was some discussion about this quite awhile ago. I was wondering if there's any interest in including a protocol 'or' type that would be the intersection of two protocols. This could be really useful in situations where a framework that the user has no control over implements a portion of some often used protocol. Such as specialized collections from an Database framework that don't implement RangeReplaceableCollection but have a set of methods that are equivalent. The user can then implement a protocol that is the intersection of those set of methods and not duplicate code.
>>
>> If the specialized collection in the database framework already provides functionality equivalent to `RangeReplaceableCollection` what you really want to do is just provide the conformance you’re looking for in an extension:
>>
>> extension SpecializedDatabaseCollection: RangeReplaceableCollection {
>> // if necessary, provide forwarding wrappers where the member names don’t match up.
>> }
>>
>> But in a case like this the framework itself really should provide this conformance out of the box. If they didn’t, maybe there is a good reason so you would want to find out why it wasn’t provided.
>>
>> Is there something you’re hoping to do that you can’t solve by simply extending the framework types?
>>
>>>
>>> Simplified example:
>>>
>>> protocol Animal {
>>> var hasEars: Bool { get }
>>> func grow()
>>> }
>>>
>>> protocol Plant {
>>> var isGreen: Bool { get }
>>> func grow()
>>> }
>>>
>>> protocol LivingThing = Plant | Animal // or a different syntax
>>>
>>> LivingThing's is as follows
>>> {
>>> func grow()
>>> }
>>>
>>> --
>>> Rex Fenley | IOS DEVELOPER
>>>
>>>
>>> Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | FOLLOW US <https://twitter.com/remindhq> | LIKE US <https://www.facebook.com/remindhq>_______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>>
>>
>> --
>> Rex Fenley | IOS DEVELOPER
>>
>>
>> Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | FOLLOW US <https://twitter.com/remindhq> | LIKE US <https://www.facebook.com/remindhq>
>
>
>
> --
> Rex Fenley | IOS DEVELOPER
>
>
> Remind.com <https://www.remind.com/> | BLOG <http://blog.remind.com/> | FOLLOW US <https://twitter.com/remindhq> | LIKE US <https://www.facebook.com/remindhq>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170202/f406da47/attachment.html>
More information about the swift-evolution
mailing list