Download the PHP package hktr92/oopize without Composer
On this page you can find all versions of the php package hktr92/oopize. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download hktr92/oopize
More information about hktr92/oopize
Files in hktr92/oopize
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package oopize
The OOPize project
This project is about making PHP more OOP-friendly place.
Imagine this: you're developing an enterprise application with Symfony and everything looks fancy and stuff...
...until you have to use explode() to split a string by a delimiter. Or to boilerplate your code with checks if a JSON
is parsed without errors (ante-PHP 7.3). Or to make sure a string is not empty.
PHP by default does not provide OOP support for scalar types, so you won't be able to do $var = "foo"; $var->empty();
to soon (even if there there is an RFC about this).
About stability
Given it's early stage, it's difficult to maintain versions. The initial idea was:
- 0.x.y version is to represent API version. When this lib will be mostly completed, 1.x.y will be released with major improvements, stability and more secure.
- x.0.y version is to represent feature class, e.g. 0.1.0 - StringUtil, 0.2.0 - added ClassUtil, etc.
- x.y.0 version is to represent feature class improvements, e.g. 0.1.1 - StringUtil fixes, 0.2.1 - ClassUtil new feature
But this is absurd to have. Sure, latest version should always have latest version from every util class. But the oldest will always be the more mature one.
And increasing the version tag after EACH commit is insanely difficult to maintain and manually do.
Given this, I recommend to always use dev-master, as it is always the latest version and contains the latest
features and fixes.
No, I won't BC stuff, v1.0.0 is happening on another branch and php-ext-oopize is happening on another repo. (Yes, I
started to rewrite these features in zephir.)
And this happens because of two things:
- this is how this project came to life (
StringUtil,NumberUtilandClassUtilwere written for one of my project) - this is how and why I maintain, extend and improve this project.
Structure
Inside Util directory, there are defined various functionality. The implementation vary, as it can be either partially
or fully static methods.
For example, StringUtil has fully static, while ArrayUtil is
partially static (as you can use $foo = new ArrayUtil;)
Inside Traits directory, you'll have traits that is targeted for class usage.
E.g. instead of calling ClassUtil::callGetter($this, 'foo'); you can call $this->callGetter('foo');.
PHP Extension
As mentioned earlier, I've started to play around with Zephir. This means that this library will be available as a PHP extension (in order to better handle memory consumption), but a PHP polyfill will be released too, based on generated IDE stubs.
All versions of oopize with dependencies
ext-ctype Version *
ext-mbstring Version *
ext-json Version *
doctrine/inflector Version ^1.3
symfony/polyfill-php73 Version ^1.13
symfony/polyfill-ctype Version ^1.13