Hi, @vudaltsov !
This library is a tremendous treasure.
The ideas expressed in the code are so good and useful that my words of appreciation would not fully express the gratitude it deserves, not ever reaching the value that it creates. It's so convenient to use it (I gave it a try some time ago), especially when it comes to union/intersection and generic types analysis - creating just one TypeVisitor for your needs, and you've done.
I think I would've used it for phphd/exceptional-matcher (right now I'm working on the linter+compiler of the mapping rules, where union/intersection and generic type analysis would be handy), but unfortunately there has not been much activity in here for the past two years, and I'm not sure it's up-to-date with typhoon-php/type, and seeing that adding it as a root composer.json dependency for my library would be a high risk, I'll probably not be likely to attempt.
I see that you did some work on the typhoon-php/type repo recently, and my honest take is this: a single package for both type&reflection would be better.
Remember how low coupling and high cohesion principles operate - things used&changed together are placed together; things used&changed apart are placed apart.
I'm sure that maintaining both type&reflection capabilities in one repository, exposed as one package, would be much easier both for you and for clients.
I can prove this by my own repository that has changed since I made a few attempts to maintain multiple closely related things in different repositories & packages. Finally, I changed it to:
Everything moved to one repo, installed as one package:
- The main library - one namespace
- Validator-integration - another namespace
- Messenger-integration - another namespace
- Uid-integration - another namespace
- Bundle (Symfony-Kernel integration) - another namespace
This is so much easier both for clients to install and for me to maintain.
Installation of the library does not install the whole stack of third-party dependencies that have integrations.
Instead, the library's composer.json only requires mere "php": ">=8.1" + low-level stuff, while third-party integration dependencies are all in "require-dev" - none of them are required for the bare core features of the library to work. Third-party libs version constraints are managed within a "conflict" section, which restricts their versions only if they are installed:
(the same as "require": { "symfony/validator": ">=6.0 && <= 8.4", ... }
One can go even further and remove the "conflict" section altogether, leaving the checks only at runtime with composer-runtime-api - so that if integration is unused, it does not constrain the whole project's dependencies.
Hi, @vudaltsov !
This library is a tremendous treasure.
The ideas expressed in the code are so good and useful that my words of appreciation would not fully express the gratitude it deserves, not ever reaching the value that it creates. It's so convenient to use it (I gave it a try some time ago), especially when it comes to union/intersection and generic types analysis - creating just one TypeVisitor for your needs, and you've done.
I think I would've used it for phphd/exceptional-matcher (right now I'm working on the linter+compiler of the mapping rules, where union/intersection and generic type analysis would be handy), but unfortunately there has not been much activity in here for the past two years, and I'm not sure it's up-to-date with typhoon-php/type, and seeing that adding it as a root composer.json dependency for my library would be a high risk, I'll probably not be likely to attempt.
I see that you did some work on the typhoon-php/type repo recently, and my honest take is this: a single package for both type&reflection would be better.
Remember how low coupling and high cohesion principles operate - things used&changed together are placed together; things used&changed apart are placed apart.
I'm sure that maintaining both type&reflection capabilities in one repository, exposed as one package, would be much easier both for you and for clients.
I can prove this by my own repository that has changed since I made a few attempts to maintain multiple closely related things in different repositories & packages. Finally, I changed it to:
Everything moved to one repo, installed as one package:
This is so much easier both for clients to install and for me to maintain.
Installation of the library does not install the whole stack of third-party dependencies that have integrations.
Instead, the library's
composer.jsononlyrequiresmere"php": ">=8.1"+ low-level stuff, while third-party integration dependencies are all in"require-dev"- none of them are required for the bare core features of the library to work. Third-party libs version constraints are managed within a"conflict"section, which restricts their versions only if they are installed:(the same as
"require": {"symfony/validator": ">=6.0 && <= 8.4", ...}One can go even further and remove the
"conflict"section altogether, leaving the checks only at runtime withcomposer-runtime-api- so that if integration is unused, it does not constrain the whole project's dependencies.