Add implementation for Result (via LlamaKit) #8

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@gfontenot
Collaborator

gfontenot commented Jan 22, 2015

Added dependency: LlamaKit for the Result type

Adding these operators for Result seems useful, since Result obeys all of the
required laws.

Looking for feedback on if this is a good idea at all. Implementation
isn't an issue, but I'm not sure what Runes' roll should be here.

Do we want frameworks that declare types that would benefit from these
operators to use Runes as a dependency and declare their own
implementations?

Or do we want to do this, and be the gatekeepers for which types (and
which implementations of which types) are "useful" enough to be
included?

Apart from that, I could use some other eyes on the documentation inside
Result.swift. Today has fried my brain something good.

Add implementation for Result (via LlamaKit)
Added dependency: LlamaKit for the Result type

Adding these operators for Result seems useful, since Result obeys all
of the required laws.
@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Jan 22, 2015

I feel that LlamaKit probably ought to define the necessary monadic operators for its own types.

I feel that LlamaKit probably ought to define the necessary monadic operators for its own types.

@sharplet

This comment has been minimized.

Show comment
Hide comment
@sharplet

sharplet Jan 22, 2015

Contributor

Yeah, if Runes brings in LlamaKit as a dependency, but then a different
library adds Runes support for itself, you've got precedent for a really
complicated dependency graph and potentially some circular dependencies if
stuff gets weird. If Runes stays pure and depends only on the standard
library, I think that will make things much easier to maintain in the long
run.

On Fri Jan 23 2015 at 8:33:32 AM Samuel E. Giddins notifications@github.com
wrote:

I feel that LlamaKit probably ought to define the necessary monadic
operators for its own types.


Reply to this email directly or view it on GitHub
#8 (comment).

Contributor

sharplet commented Jan 22, 2015

Yeah, if Runes brings in LlamaKit as a dependency, but then a different
library adds Runes support for itself, you've got precedent for a really
complicated dependency graph and potentially some circular dependencies if
stuff gets weird. If Runes stays pure and depends only on the standard
library, I think that will make things much easier to maintain in the long
run.

On Fri Jan 23 2015 at 8:33:32 AM Samuel E. Giddins notifications@github.com
wrote:

I feel that LlamaKit probably ought to define the necessary monadic
operators for its own types.


Reply to this email directly or view it on GitHub
#8 (comment).

@mattrubin

This comment has been minimized.

Show comment
Hide comment
@mattrubin

mattrubin Jan 23, 2015

I'm not sure Runes is the right place for the Result operators. I use both Runes and LlamaKit, and I like these operators, but I think the role of Runes as a focused micro-framework means it shouldn't introduce larger and possibly-unwanted dependencies to projects which include it.

I'd rather have LlamaKit include Runes and provide these operators for its own type. If the LlamaKit maintainers don't think this is right for inclusion in the main body of LlamaKit, perhaps the best solution is a "LlamaKitRunes" framework that links both LlamaKit and Runes and adds the Result operators.

I'm not sure Runes is the right place for the Result operators. I use both Runes and LlamaKit, and I like these operators, but I think the role of Runes as a focused micro-framework means it shouldn't introduce larger and possibly-unwanted dependencies to projects which include it.

I'd rather have LlamaKit include Runes and provide these operators for its own type. If the LlamaKit maintainers don't think this is right for inclusion in the main body of LlamaKit, perhaps the best solution is a "LlamaKitRunes" framework that links both LlamaKit and Runes and adds the Result operators.

@gfontenot gfontenot closed this Feb 16, 2015

@gfontenot gfontenot deleted the gf-result branch Feb 16, 2015

@gfontenot

This comment has been minimized.

Show comment
Hide comment
@gfontenot

gfontenot Feb 16, 2015

Collaborator

After thinking about this for a while, I agree with the general sentiment in here. I don't think Runes is the place to add this. The dependency should be the other way around.

Collaborator

gfontenot commented Feb 16, 2015

After thinking about this for a while, I agree with the general sentiment in here. I don't think Runes is the place to add this. The dependency should be the other way around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment