Merge cvogt/compossible's Records and scala-records #112

Open
cvogt opened this Issue Mar 17, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@cvogt

cvogt commented Mar 17, 2015

After dicussing with @gzm0 extensively over the weekend, we realized that my macros in compossible and scala-records actually are still quite complimentary in their features rather than competitive. We should strongly consider joining forces i.e. merging I think. This requires agreement on #111 first. Apart from that we seem to have made the same design decisions or complement each other. compossible implements fully blackbox Record create, merge and select operations (and nicer syntax whitebox alternatives), explicit and optional implicit conversions from/to case classes and anonymous classes. I have also written a play-json deserializer for these records, which will be the first use case for which we will start using them in production at @xdotai. I am still missing equality comparison, hashCode and these things, which you guys already have. I am also missing pattern matching yet. That multi-backend feature is nothing I would have implemented for mine, but I can see the importance of this for certain use cases.

I'd be happy to merge and join forces. I am ok with migrating my stuff into Scala Records if we can agree on all design decisions. Also, I'd like to stabilize and finalize a small core soon so I can use it in production and go form there.

My Scala Days talk is about my implementation by the way, which you might want to check out.

@cvogt

This comment has been minimized.

Show comment
Hide comment
@cvogt

cvogt Mar 17, 2015

First design decision: I tried to stay blackbox whenever possibly or write whitebox macros that provide enough type info in their signature to suffice for code completion in IntelliJ. In case the best whitebox Syntax is significantly better than the best blackbox syntax, I want to offer both versions. Examples:

Create records:
Record(name="Chris", age=99) // whitebox
Record(new{def name="Chris"; def age=99}) // blackbox

Select:
r.select[{def age: String}] // blackbox
r.select(_.age) // whitebox

While this is a minor thing, I'd also like to see Record be called Record rather than Rec. People can always import {Record => Rec} if they want, but Record is just clearer IMHO.

cvogt commented Mar 17, 2015

First design decision: I tried to stay blackbox whenever possibly or write whitebox macros that provide enough type info in their signature to suffice for code completion in IntelliJ. In case the best whitebox Syntax is significantly better than the best blackbox syntax, I want to offer both versions. Examples:

Create records:
Record(name="Chris", age=99) // whitebox
Record(new{def name="Chris"; def age=99}) // blackbox

Select:
r.select[{def age: String}] // blackbox
r.select(_.age) // whitebox

While this is a minor thing, I'd also like to see Record be called Record rather than Rec. People can always import {Record => Rec} if they want, but Record is just clearer IMHO.

@vjovanov

This comment has been minimized.

Show comment
Hide comment
@vjovanov

vjovanov Mar 17, 2015

Contributor

We converged on Rec after many trials and lengthy discussions. If you really do not like it we can ask the crowd to vote for this at scala-days. I can make a form in google docs :)

Contributor

vjovanov commented Mar 17, 2015

We converged on Rec after many trials and lengthy discussions. If you really do not like it we can ask the crowd to vote for this at scala-days. I can make a form in google docs :)

@vjovanov

This comment has been minimized.

Show comment
Hide comment
@vjovanov

vjovanov Mar 17, 2015

Contributor

Overall, I support this effort. Scala Records are already packed with tests and very stable. If we can make the new approach satisfy all the requirements I am all in on joining forces.

Contributor

vjovanov commented Mar 17, 2015

Overall, I support this effort. Scala Records are already packed with tests and very stable. If we can make the new approach satisfy all the requirements I am all in on joining forces.

@cvogt

This comment has been minimized.

Show comment
Hide comment
@cvogt

cvogt Mar 17, 2015

Ok, then let's focus on the semantic parts first and assuming this all works out fine, we can re-open the discussion on that name.

cvogt commented Mar 17, 2015

Ok, then let's focus on the semantic parts first and assuming this all works out fine, we can re-open the discussion on that name.

@Ciantic Ciantic referenced this issue in cvogt/compossible Jan 31, 2016

Open

Destructuring a TMap in typeclasses #15

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