[swift-evolution] Either protocol syntax

Rex Fenley rex at remind101.com
Thu Feb 2 16:02:04 CST 2017


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.

On Thu, Feb 2, 2017 at 1:53 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> On Feb 2, 2017, at 3:46 PM, Rex Fenley <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>
> wrote:
>
>>
>> On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution <
>> 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
>> 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/cc1cd7e4/attachment.html>


More information about the swift-evolution mailing list