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

Add :default to colorize and document ColorRGB, Color256 #6427

Merged
merged 5 commits into from Sep 16, 2018

Conversation

wooster0
Copy link
Contributor

I think it would be good when you can just write:

"hello".colorize(:default)

instead of:

"hello".colorize(Colorize::ColorANSI::Default)

@Sija
Copy link
Contributor

Sija commented Jul 22, 2018

Would be nice to document what actually is the default color. Or even remove it altogether since without context IMHO having default doesn't make much sense...

@straight-shoota
Copy link
Member

With #6074 "hello".colorize(:default) should just work if the argument type for Object#colorize is restricted to ColorANSI.

@wooster0
Copy link
Contributor Author

wooster0 commented Jul 22, 2018

@Sija having :default is definitely handy sometimes. Especially in conditions like:

puts "hello".colorize(some_bool ? :green : :default)

so :default prevents some complexity. If it wouldn't exists you would have to do something like:

if some_bool
  puts "hello".colorize(:green)
else
  puts "hello"
end

The :default color just leaves the string as it is (but it's an Colorize::Object(String) object then). I think I'll add a note about that in the documentation.

@straight-shoota So you mean adding

def colorize(fore : Colorize::ColorANSI)
   Colorize::Object.new(self).fore(fore)
end

would be better?
nvm: I get what you mean

@hanyuone
Copy link

Because of #6074, shouldn't we just remove all existing symbols in COLORS and just let the compiler handle all of it?

@Sija
Copy link
Contributor

Sija commented Jul 28, 2018

@Qwerp-Derp problem with #6074 is that it allows only passing symbol literals, it ain't work if you use variables for instance.

@hanyuone
Copy link

hanyuone commented Jul 29, 2018

@Sija Why would you ever use anything other than a symbol literal in this case? If you were to use a variable, why not just use the full name of the enum?

a = Colorize::ColorANSI::Default
"foo".colorize(a)

I agree something like "foo".colorize(Colorize::ColorANSI::Default) is ugly, but only because the line is unnecessarily long. If you split it up into a variable I personally think it's fine, but that's just my 2c on the issue.

Therefore, I still think we should get rid of all the symbols in COLORS, or at least change the String#colorize method itself to implement #6074.

@asterite
Copy link
Member

Yeah, using enums now should be the way to go.

@DestyNova
Copy link

I think Enums would be much better, because at the moment it's very easy to get runtime errors that should have been caught at compile-time:

$ crystal build hello.cr
$ ./hello
Unhandled exception: Unknown color: purple (ArgumentError)
  from /usr/share/crystal/src/colorize.cr:244:5 in 'fore'
  from /usr/share/crystal/src/colorize.cr:118:5 in 'colorize'
  from hello.cr:3:8 in '__crystal_main'

@makenowjust
Copy link
Contributor

I forgot to add default to COLORS when added ColorANSI. So it is just bug.

This PR looks totally good and it should be merged ASAP. Using enum instead symbol is another and wider topic than this PR. Should talk in new issue.

@r00ster91 Thank you! And sorry for missing this.

Copy link
Member

@sdogruyol sdogruyol left a comment

Choose a reason for hiding this comment

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

Thank you @r00ster91 👍

@sdogruyol sdogruyol merged commit 13fe0f4 into crystal-lang:master Sep 16, 2018
@sdogruyol sdogruyol added this to the 0.27.0 milestone Sep 16, 2018
ezrast pushed a commit to ezrast/crystal that referenced this pull request Oct 2, 2018
RX14 pushed a commit to RX14/crystal that referenced this pull request Oct 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants