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

Fix for issue #2 prevent lc on uninit var #3

Merged
merged 1 commit into from Jun 16, 2016

Conversation

Projects
None yet
3 participants
@lancew
Contributor

lancew commented Jun 15, 2016

Prevent the calling of lc on uninitialised value.

Hi, as part of the PRC I took a look and spotted this outstanding issue. Written a quick fix and test.
All tests pass, but you might have opinion on if what I have done suits what you would like to see in the code.
Lance

Fix for issue #2 prevent lc on uninit var
Prevent the calling of lc on uninitialised value.
@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Jun 15, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling 49b91c7 on lancew:master into 7d4a822 on kablamo:master.

coveralls commented Jun 15, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling 49b91c7 on lancew:master into 7d4a822 on kablamo:master.

@kablamo kablamo merged commit 52b201f into kablamo:master Jun 16, 2016

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 100.0%
Details
@kablamo

This comment has been minimized.

Show comment
Hide comment
@kablamo

kablamo Jun 16, 2016

Owner

Nice! Its awsome that you wrote a test for it thank you. I thought it was kinda cool how I had 100% test coverage but still had a bug.

Owner

kablamo commented Jun 16, 2016

Nice! Its awsome that you wrote a test for it thank you. I thought it was kinda cool how I had 100% test coverage but still had a bug.

@kablamo

This comment has been minimized.

Show comment
Hide comment
@kablamo

kablamo Jun 16, 2016

Owner

hmmm

kebab_case("____"); # returns empty string

I'm not sure what it should return. I think it should return "____". Or "----"....

Owner

kablamo commented Jun 16, 2016

hmmm

kebab_case("____"); # returns empty string

I'm not sure what it should return. I think it should return "____". Or "----"....

@kablamo

This comment has been minimized.

Show comment
Hide comment
@kablamo

kablamo Jun 16, 2016

Owner

I don't know... it doesn't make a lot of sense to ask someone to camel case or kebab case a string like "___" or "- ". Maybe it should just die. I'm already returning "" when a user passes in "" though. Probably should have died when they passed in "".

Owner

kablamo commented Jun 16, 2016

I don't know... it doesn't make a lot of sense to ask someone to camel case or kebab case a string like "___" or "- ". Maybe it should just die. I'm already returning "" when a user passes in "" though. Probably should have died when they passed in "".

@kablamo

This comment has been minimized.

Show comment
Hide comment
@kablamo

kablamo Jun 16, 2016

Owner

Ok I think I like this solution. I did a release for this. Should show up on cpan soon.

Owner

kablamo commented Jun 16, 2016

Ok I think I like this solution. I did a release for this. Should show up on cpan soon.

@lancew

This comment has been minimized.

Show comment
Hide comment
@lancew

lancew Jun 16, 2016

Contributor

Yeah, I tended to think along same lines as you that dieing might be fine; but like you spotted the existing "" returns "" and thought my change pretty much replicates that approach.
Glad to contribute

Contributor

lancew commented Jun 16, 2016

Yeah, I tended to think along same lines as you that dieing might be fine; but like you spotted the existing "" returns "" and thought my change pretty much replicates that approach.
Glad to contribute

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