Modernization of the library to make it usable in modern PHP applications #4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently this SDK isn't really usable in modern PHP applications due to it's vast usage of the global namespace which has long since been retired as a best practice. Additionally, it does not have the metadata needed to be included into modern PHP projects via the PHP package manager composer.
This PR fixes both issues. Essentially what I've done is a simple wrapping of all the global namespaced functions into the
Mapcode
namespace. I then created an object to hold all the global variables / lookup tablesMapcodeData
and updated all the references to$GLOBALS
to use theMapcodeData::$varname
equivalent`.I also cleaned up the autoloading a tad and added a
composer.json
which can then be registered at https://packagist.org so others can easily use the library.Along with these changes I updated the sample, unit tests (all passing), and documentation to reflect how it can be used. I updated the version to 2.3.0, although I think arguably it would make sense to call this 3.0.0.
All of these changes were necessary in order to use the library in any sort of professional PHP application context, and if necessary we'll maintain this as our own fork of the original SDK -- but I'd love to see this PR merged so we won't have to do that!