[swift-users] Associatedtype Naming Conventions

[Dave Abrahams]

on Wed May 31 2017, Steven Brunwasser <swift-users-AT-swift.org> wrote:

> Yes, I understand this. I was just wondering if there was a naming
> convention I should use to differentiate them.

I would try to find something more specific and descriptive than
“Container” and “Element” if you think there's a chance they would ever
arise as associated types of the same type but with distinct identity.

Another possibility, if you think that might be about to happen, is that
you're using conformance when you should use aggregation.  For example,
an Int has everything it needs to be a Sequence and/or Iterator (n to
infinity), a Collection (of numbers from zero to its bitWidth), etc.,
but *should* it conform to those protocols?  IMO probably not.  If you
find yourself hard pressed to describe what something *is* in a few
words, it may be conforming to too many protocols.

> Should I use a few letters as a prefix? Should I use the full protocol name
> as a prefix? Or is there another suggestion for a naming convention?
>
> I'm also curious about any naming conventions I should use to get around
> collisions with other libraries' protocol associatedtypes.
>
> On May 31, 2017 at 16:26:52, Slava Pestov (spestov at apple.com) wrote:
>
>>
>> On May 31, 2017, at 4:16 PM, Steven Brunwasser <sbrunwasser at gmail.com>
>> wrote:
>>
>> Basically, my library contains a bunch of collection-like protocols, which
>> can be combined in different ways and can be compatible with each other in
>> certain combinations when the proper types align. Naturally, they all have
>> an Element associatedtype, but I need to allow for the possibility where
>> two of these collection protocols are implemented in the same structure
>> that requires different type definitions for each protocols' Element.
>>
>>
>> Oh, I understand now. This is intentionally not supported — associated
>> types with the same name from different protocols must all be implemented
>> by the same typealias in the conforming type.
>>
>> Slava
>>
>>
>> I’ve been trying to make some other protocols to simplify some
>> definitions, but specifying a parent protocol’s associated type within a
>> child protocol doesn’t seem to work.
>>
>> protocol Buzz: Bar {
>> typealias Container = A
>> }
>>
>> struct BuzzImpl: Buzz {} // *error: type ‘BuzzImpl' does not conform to
>> protocol ‘Buzz'*
>>
>> On May 31, 2017 at 4:02:43 PM, Slava Pestov (spestov at apple.com) wrote:
>>
>> Can you give an example of a problematic name collision? Does fully
>> qualifying names not help?
>>
>> Slava
>>
>> On May 31, 2017, at 4:01 PM, Steven Brunwasser via swift-users <
>> swift-users at swift.org> wrote:
>>
>> Hi,
>>
>> I have a library which uses a few generic protocols with identically named
>> associated types that may not always be specified identically by
>> implementors.
>>
>> protocol Foo {
>> associatedtype Container
>> associatedtype Element
>> }
>>
>> protocol Bar {
>> associatedtype Container
>> associatedtype Element
>> }
>>
>> struct Baz: Foo, Bar {
>> // Implement using two different Container/Element types.
>> }
>>
>> Is there a consensus on some naming convention for associatedtypes to
>> mitigate name collisions?
>> Would it be acceptable to add namespace prefixes to these types?
>>
>> protocol Foo {
>> associatedtype FooContainer
>> associatedtype FooElement
>> }
>>
>> I’m using the dictionary and thesaurus to find some alternative names I
>> could use, but the ones already used are so the most sensical semantically.
>>
>> Do you have any suggestions?
>>
>> Thanks,
>> - Steve Brunwasser
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>

-- 
-Dave