Skip to content
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

Adds Show[Stream] #775

Merged
merged 1 commit into from
Jan 5, 2016
Merged

Adds Show[Stream] #775

merged 1 commit into from
Jan 5, 2016

Conversation

mikejcurry
Copy link
Contributor

Adds a Show instance for Stream.

Of note, unlike Stream.toString, this proposed implementation is referentially transparent.

A test exists for this property.

I thought about adding some checks in that test to demonstrate that toString exhibits behaviour that violates referential transparency, but I thought that would be too brittle to included in this test, as if a future Scala version rectifies this behaviour inStream, then the test might break, which might not be nice. It is straightforward to add something that shows this however.

@codecov-io
Copy link

Current coverage is 88.49%

Merging #775 into master will increase coverage by +0.01% as of 4b424b8

@@            master    #775   diff @@
======================================
  Files          166     166       
  Stmts         2283    2285     +2
  Branches        74      75     +1
  Methods          0       0       
======================================
+ Hit           2020    2022     +2
  Partial          0       0       
  Missed         263     263       

Review entire Coverage Diff as of 4b424b8

Powered by Codecov. Updated on successful CI builds.

@non
Copy link
Contributor

non commented Jan 4, 2016

Looks great to me! Thanks for ensuring referential transparency.

👍

@@ -58,6 +59,11 @@ trait StreamInstances {
override def isEmpty[A](fa: Stream[A]): Boolean = fa.isEmpty
}

implicit def streamShow[A: Show]: Show[Stream[A]] =
new Show[Stream[A]] {
def show(fa: Stream[A]): String = if(fa.isEmpty) "Stream()" else s"Stream(${fa.head.show}, ?)"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the .show syntax here will result in an extra allocation for the ShowOps object, right? In this particular case that probably doesn't matter, but it may be worth having a convention of not using syntax when it comes at an allocation cost in Cats. I don't know. What do people think?

@ceedubs ceedubs mentioned this pull request Jan 5, 2016
@ceedubs
Copy link
Contributor

ceedubs commented Jan 5, 2016

I'm going to go ahead and merge. This is a useful instance and we can always revisit the syntax usage later.

ceedubs added a commit that referenced this pull request Jan 5, 2016
@ceedubs ceedubs merged commit 8b3c015 into typelevel:master Jan 5, 2016
@mikejcurry
Copy link
Contributor Author

@ceedubs - sorry for the delay in responding. Thanks for merging!

With regard to the use of the .show syntax, I think you're right and with the current syntax it would be an extra allocation here (and with Vector and List instances an allocation per item).

I'm just wondering aloud whether it might be better to investigate what might be possible with value classes/simulacrum/machinist to reduce/remove the cost of using syntax here, instead of imposing the convention and fall back to the convention if we can't get the desired results.

It would be nice for users of cats not to have to consider this also so it would be valuable in that sense too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants