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

alnum() misleading, should use ctype_alnum() #78

Open
webmozart opened this issue Dec 18, 2014 · 11 comments
Open

alnum() misleading, should use ctype_alnum() #78

webmozart opened this issue Dec 18, 2014 · 11 comments

Comments

@webmozart
Copy link
Contributor

Currently, Assertion::alnum() tests that a value consists of alphabetic and numeric characters only and starts with a letter. I think this is misleading, as it is different to what ctype_alnum() does.

I think that alnum() should be changed to use ctype_alnum() internally, moreover helpers for the other ctype_*() functions should be implemented.

We can add another helper testing that a string starts with a letter: startsWithLetter (using ctype_alpha($string[0]) internally) - analogous to startsWith

What do you think?

@beberlei
Copy link
Owner

ctype is locale dependent, all our code does not depend on environment right now.

@webmozart
Copy link
Contributor Author

Really? Got to do some research then.

@beberlei
Copy link
Owner

@webmozart See http://php.net/manual/en/function.ctype-alnum.php its reference to "default locale" and the link to setlocale.

@mdavis1982
Copy link
Contributor

I agree with @webmozart that this is confusing. I would expect that an alphanumeric check would mean that something like 123abc would also pass because the content of it is alphanumeric.

Maybe the check that it starts with a letter could be removed @beberlei?

@webmozart
Copy link
Contributor Author

@mdavis1982 as far as I see, the problem is that this would break backwards compatibility of the library. You can find a very similar library where this and some other small issues are fixed here though: https://github.com/webmozart/assert

@mdavis1982
Copy link
Contributor

@webmozart Of course. This could be fixed and tagged as a different version though? I'd like to contribute to the library to fix issues such as these (I'm going through all of the issues now). Do you think you could possibly contribute some of your other assertions to this library?

@webmozart
Copy link
Contributor Author

@mdavis1982 That's what I tried, but @beberlei said he didn't want to make breaking changes.

@beberlei
Copy link
Owner

its not really a breaking change, because we are making the validation less strict. Making it stricter would be a problem though. I consider this a bug, if alnum actually means starting with 123 is allwoed as well.

@ghost
Copy link

ghost commented Sep 26, 2019

Hi,

I'd like to draw your attention to this issue again since we're using the library a lot in our applications and find the nuance problematic when using alnum check from time to time. It says that "123" is not alphanumeric which, of course, is not true and is simply a bug. This forces us to write unnecessary regexes or manually use ctype_alnum

Any plans on fixing it soon?

@rquadling
Copy link
Contributor

Hi. I'm happy to accept PRs on this. I'm sort of the de-facto maintainer now, but the library is still @beberlei's.

As for BCs, I'm using semantic versioning (and nearly fully understanding it!!! Yay! Please excuse the hiccough in the V3.2 version .. should all be sorted now!), so a v4 and a clear differentiation would be nice, but things would really need to be tested as we don't all work in all environments.

@rquadling
Copy link
Contributor

Also, as you are able to subclass the Assert library now, you may find it "simpler" to implement your own assertions on top of Assert.

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

No branches or pull requests

4 participants