[Breaking] Update on naming

[jessesquires]

I recently gave a talk about the ideas in this framework:
https://speakerdeck.com/jessesquires/pushing-the-limits-of-protocol-oriented-programming

The talk presented a much simplified version of everything. In writing the talk and trying to explain all of the different components, I realized we could improve naming:

• ReuseableViewFactoryProtocol --> ReusableViewConfiguringProtocol
• ViewFactory --> ViewConfig

I never really like the "factory" name. This is much better.

NOTE: not accepting PRs for this. ⚠️

[dcaunt]

Love the slides, they're a really nice explanation of the current design!

Improving the names makes sense, although currently ReuseableViewFactoryProtocol is used for configuring both cells and supplementary views, so we should think about that name. Out of curiosity, what rule are you using to decide if the protocol name ends with Protocol? I couldn't find a good guideline for Swift 3 on when to use this suffix specifically.

On the subject of breaking changes and the current design, have you considered #31 any further?

[jessesquires]

Thanks @dcaunt ! 🙌

Improving the names makes sense, although currently ReuseableViewFactoryProtocol is used for configuring both cells and supplementary views, so we should think about that name.

Sounds good. We can keep "View" instead of "Cell". Issue updated.

Out of curiosity, what rule are you using to decide if the protocol name ends with Protocol?

Swift 3 established this precedent, so I've just been following that. But I'm open to ideas.

[dcaunt]

I'm just curious as the API Design Guidelines cover nouns and capabilities but don't make an explicit statement about ...Protocol, as far as I can see.

Looking at the Swift std lib, it appears to be used where the Protocol name would conflict/be similar to a concrete type e.g. LazyCollection and LazyCollectionProtocol, though IteratorProtocol doesn't conflict with a type Iterator (but could conceivably in future).