Closed jwpage closed 6 years ago
Probably doesn't really matter, but I'd make the methods non-static at that point. Feels odd to have a factory and then not use the created instance.
Thanks for the pull request @jwpage! It is awesome that you're taking the time to optimise this library.
There are a couple of thing we need to adjust before showing this to @ivanakimov:
We should also note that this change will require a new major release since this is a breaking change.
Probably doesn't really matter, but I'd make the methods non-static at that point. Feels odd to have a factory and then not use the created instance.
I agree, we should make the methods non-static.
I couldn't figure out a way to disable extensions at runtime (either command-line or in PHP), so Hashids\Math\MathFactory is marked as @codeCoverageIgnore. đ (Considered adding a bitmask parameter to the constructor to force disabling GMP and/or BC, but is it worth it?)
Hmm, not sure. In what case would we want to enforce this? Lets skip that for now.
tests/Hashids/RuntimeExceptionTest.php
also can't be run properly, as there's no way to force disabling extensions at runtime. Could this test be removed instead? đ¤ˇââď¸
Lets drop the test entirely for now.
Thanks for the feedback, @vinkla. Hopefully have ticked off all the the issues.
If this is going to be a new major version, I'll go ahead and remove the Hashids\Math
class as it's no longer used. I'd also maybe recommend adding @api/@internal
docblock tags to indicate what Structural Elements are supported for future backwards compatibility (only Hashids::__construct
, Hashids::encode
, Hashids::decode
?)
If this is going to be a new major version, I'll go ahead and remove the
Hashids\Math
class as it's no longer used. I'd also maybe recommend adding@api/@internal
docblock tags to indicate what Structural Elements are supported for future backwards compatibility (onlyHashids::__construct
,Hashids::encode
,Hashids::decode
?)
Sounds like a good idea.
Sounds like a good idea.
I might leave @api/@internal tagging for a different 3.0-related PR, as that's not directly related to this PR.
@ivanakimov now the final decision is up to you. This pull request LGTM. What is your opinion?
This is great :smile:
@jwpage, I agree with @vinkla -- thanks for taking the time to optimize the code! And @vinkla, thanks for such quick responses and taking the lead :muscle: Feel free to release whenever you're ready!
Thanks for the pull request @jwpage! I'll bump the branch alias to 3.0 and then we can test the new version a couple of days before releasing it. Let me know if you've any questions!
I noticed that the current
Hashids\Math
class is making a function_exists check with each function call, which was quite slow. I've replaced it with aHashids\Math\MathFactory
that checks if the relevant extension (gmp/bcmath) is loaded instead, which returns aHashids\Math\MathInterace
class.I've tried to retain backwards compatibility by using the
MathFactory
inside the (deprecated, no longer used)Hashids\Math
class as well.Here are a couple of blackfire.io profiles for encoding 50,000 hashes.
đ¨ A couple of things that need fixing/addressing:
Hashids\Math\Gmp
andHashids\Math\Bc
can both be tested directly in the standard testsuite (tests/Math/MathInterfaceTest.php
), so the disable_functions options in.travis.yml
have been removed.Hashids\Math\MathFactory
is marked as@codeCoverageIgnore
. đ (Considered adding a bitmask parameter to the constructor to force disabling GMP and/or BC, but is it worth it?)tests/Hashids/RuntimeExceptionTest.php
also can't be run properly, as there's no way to force disabling extensions at runtime. Could this test be removed instead? đ¤ˇââď¸