Conveniences ought to have a home

[robrix]

We’ve had a few PRs along the lines of #123, where someone has submitted a scratch for a not-uncommon itch. We’ve been turning them down—mostly—thus far, but maybe we should instead be finding them a better home.

As I understand it, this is the sort of thing that git’s contrib dir exists to enable. Maybe we should consider something similar. Some ideas:

• a Contrib (sub?)framework encapsulating conveniences and experiments
• a section of the readme linking to gists with these things
• just including them in the framework and being done with it

[NachoSoto]

I like the idea! Especially as a separate framework.

[gfontenot]

I love the idea of linking to gists or providing a Contrib framework alongside Result. I don't think we should be including them in the main framework though.

[neilpa]

The one problem with a Contrib style framework in the same repo is it doesn't play all that nice with carthage.

[NachoSoto]

I was thinking it'd be a different repo for that reason.

[Thomvis]

Agreed, a separate framework & repo seems the best approach. In my experience however it is easy for the two frameworks to get out of sync, e.g. If you forget to update the contrib after a PR in the main repo. Is there a proven process for this?

Just my 5 cents for the name: ResultOriented.framework

[NachoSoto]

If you forget to update the contrib after a PR in the main repo. Is there a proven process for this?

Well the "contrib" version would reference a specific Result version so compatibility would always be explicit.

That also means that one can simply change their Carthage reference from Result to this other framework, and their existing usages of Result would continue to work.

[Thomvis]

Well the "contrib" version would reference a specific Result version so compatibility would always be explicit.

Understood. I was hoping there was some sort of safeguard/check that would prevent the contrib library from lagging behind.

[robrix]

@Thomvis: We could add it as a private dependency and then test it.

Just my 5 cents for the name: ResultOriented.framework

👏 I love it 😄

[kylef]

In my experience however it is easy for the two frameworks to get out of sync, e.g. If you forget to update the contrib after a PR in the main repo.

Since Result just hit 1.0, I'd expect the API to be pretty stable and at least no backwards incompatible changes anytime soon. So I wouldn't expect this to be a problem.

[robrix]

Can we provide the contrib stuff in a submodule of the Result module? e.g.:

import Result.Oriented

let 🎉 = …

If so, we could ship it in this repo, which would be a lot more convenient both for contributors and end users. Presumably Carthage wouldn’t be too fussed since it’d end up being in the same compilation unit, just a separate namespace? (I’m not entirely sure how any of that works!)

[Evertt]

So uh, did this ever turn into something tangible?

[robrix]

@Evertt: Not thus far.

[Evertt]

Too bad, I really liked the idea. I happen to be a great fan of automagic stuff and since I know it won't be implemented in this library I'd love to know there's a central place where I can find plugins like that.

[robrix]

@Evertt: Nothing’s been established yet, but that’s not to say that you couldn’t be the one to establish it, if you want. If you’re interested, I’d suggest starting very minimally, so that the contrib stuff’s home can be reviewed independently of any conveniences added therein.