Closed tschallacka closed 6 years ago
All classes except the facade are namespaced. Using class_alias
to put it back where it is now kind of defeats the purpose doesn't it? You also lose any benefit from autoloading (As opposed to what exists now) since the target class has to exist when you call it.
Is there any practical benefit to namespacing it?
composer autoloading by just having a namespace with the psr-4 method and root directory :-)
By using the class alias you still make it an utility method, much like laravel uses it's facades, which also not reside in the root namespace but are aliassed to the root namespace in some applications.
Also, the root namespace should ideally be reserved for the web application that uses it, and support libraries in their own namespace away from class_exists errors and function already defined errors.
It's a polite way of staying out of the utilizing developers way.
It's a polite way of not working - either you alias and instantiate while loading the package just like now or the user has to run some sort of init command or function to create the helpers and alias the class themselves after including composer's autoload.
So in other words, we'd have psr4 autoloading but still need to manually initialize on load and reserve the root level class name.
Hey it's your project. Not here to start a fight. It's just a suggestion.
But looking at other libraries, there is always some sort of initializer, take Carbon\Carbon::now().
You can also include in your own composer.json "files": ["src/helpers.php"] to register global to tests functions and run an init function if needed.
You can also make things TOO easy for developers, which causes them NOT to think about all the things your classes add, but it also takes away the option for them to keep their namespace clean.
Prefably I'd have a define('KINT_REGISTER_GLOBAL_NAMESPACE',false) option possible, so Kint won't register itself in the global namespace and I can just do use Kint\Kint when I need Kint.
If you don't want it, you can just close this issue and keep coding on :-) I can always just move it into it's own namespace after checking out.
It's just a suggestion.
And I'm open to it which is why this issue is still open
You can also include in your own composer.json "files": ["src/helpers.php"] to register global to tests functions and run an init function if needed.
That's how kint already works, or do you mean in the end-user's composer.json?
I definitely want the out of the box kint experience to be as simple as possible. An init function is out of the question.
An option to make \Kint
a global alias that's opt-out the same way the helpers are now might be an idea. I'll consider it for the next branch
Cool 👍
If I understand composer correctly, it will also execute statements in your composer.json, hence the dependencies loading. So if you define it in your composer.json that your "init" file loads that the user now has to include in his php code, you can still keep both options open.
For those going "vanilla" can still do require_once "kint.php";
For those using composer will have everything automatically initialized when the "files": ["kint.php"] get's executed.
The define option to disable auto global namespace can also help with people who want to use Kint as a laravel Service Provider instead of the standard laravel dump method. That way they can interchange it with existing code without having to rename all the methods.
For those going "vanilla" can still do require_once "kint.php"; For those using composer will have everything automatically initialized when the "files": ["kint.php"] get's executed.
Again, that's how it works already
The define option to disable auto global namespace can also help with people who want to use Kint as a laravel Service Provider instead of the standard laravel dump method. That way they can interchange it with existing code without having to rename all the methods.
I don't see how unless you're partial to putting kint config in your index before your autoloader include... That's why it currently parses composer files first
@tschallacka could you please test 19b48f6e5abcf7cf846072dc8ac49c5e96873fdc?
It now has an opt out composer option for the toplevel Kint class just like the helpers, and defining constants before including the phar or autoloader should achieve the same effect.
I want to check it out, but I can't clone it, git keeps saying that it doesn't exist. On which tag/tree/commit should I pull?
$ git checkout 19b48f6e5abcf7cf846072dc8ac49c5e96873fdc fatal: reference is not a tree: 19b48f6e5abcf7cf846072dc8ac49c5e96873fdc
$ git checkout 19b48f6 error: pathspec '19b48f6' did not match any file(s) known to git.
Ah you'll have to look at my local fork jnvsor/kint test branch IIRC
19b48f6
For PSR-4 compliant projects namespaces are needed for easy autoloading by PSR-4 standards
https://www.php-fig.org/psr/psr-4/
Currently Kint has no namespace.
Would it be possible to put Kint into it's own namespace?
you can then use class_alias() to put kint back into the main root namespace.
http://php.net/manual/en/function.class-alias.php
class_alias('Kint\Kint','Kint');