New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mixable tree/map traits #1

Open
wants to merge 8 commits into
base: develop
from

Conversation

Projects
None yet
1 participant
@erikerlandson
Member

erikerlandson commented Aug 29, 2016

A couple comments:

  1. As currently implemented, these have an algebird dependency, which means "isarn_collections" has an algebird dep.
  2. You can see I'm assuming we are going to use domain name "isarnproject.org"
  3. I'm using underscores in names "isarn_collections" because sbt isarn-collections/compile doesn't work, but isarn_collections/compile does
@erikerlandson

This comment has been minimized.

Show comment
Hide comment
@erikerlandson

erikerlandson Aug 29, 2016

Member

Possibly it would help to just use % "provided" for the algebird lib.

Another approach might be to have our own internal algebra types, and require implicit conversions in the signatures, with a separate subproject for conversions from external algebra libs to ours. That gets rid of any external algebra lib deps and allows us to operate with multiple ones

A third option is to be opioninated wrt one of these algebra libs (I might favor cats these days), but require implicit conversions, and so allow other libs to interoperate. Would this allow us to not expose the dependency?

Member

erikerlandson commented Aug 29, 2016

Possibly it would help to just use % "provided" for the algebird lib.

Another approach might be to have our own internal algebra types, and require implicit conversions in the signatures, with a separate subproject for conversions from external algebra libs to ours. That gets rid of any external algebra lib deps and allows us to operate with multiple ones

A third option is to be opioninated wrt one of these algebra libs (I might favor cats these days), but require implicit conversions, and so allow other libs to interoperate. Would this allow us to not expose the dependency?

@erikerlandson

This comment has been minimized.

Show comment
Hide comment
@erikerlandson

erikerlandson Sep 18, 2016

Member

@willb I have the tree/map collections decoupled from algebird (except in testing)

Member

erikerlandson commented Sep 18, 2016

@willb I have the tree/map collections decoupled from algebird (except in testing)

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