as you might know I am deeply into splitting Flow to separate packages. Specifically packages that can be reused outside of Flow. I am making good progress but I would like to discuss a few specifics:
I already split ObjectAccess off but that strongly depends on Utility\TypeHandling. Now this utility should be split anyway, but I am not decided if I want to put that into another separate package or just into the same with the ObjectAccess. WDYT?
Then the other utilities. They are a pretty mixed bag and I want to unclutter that.
So currently I have the following groups in mind:
Arrays
PositionalArraySorter
SchemaGenerator
SchemaValidator
Then Now and Environment will stay in Flow because tightly coupled and very specific and the rest of the utilities (Files, Algorithms, MediaTypes, OpcodeCacheHelper, PdoHelper, PhpAnalyzer) could be separate.
And again WDYT?
More to come, but for now I would like to proceed with this first.
Phew. splitting the utility namespace out, of course. But “explode” that into multiple packages itself, hm… I get the “small packages” idea, but IMHO it get’s weird at some point.
Yeah, I mean the utilities don’t have much outside dependencies (besides Algorithms, that could also stay in “core”) so it wouldn’t make much difference. It’s only a question if people are willing to install 9 (for them) useless classes to get the one they want. I am also fine with keeping the utilities all together, but at least the schema stuff should be separated as it is more than utilities IMHO.
How do people feel about that? Lets say you need a method from the Array or Files Utility in a non Flow project. Would it be ok for you to have the rest of the utilities laying around there as well?
a package should have as little dependencies as possible.
a package should contain all classes needed to be functional for it’s task.
a package can contain multiple classes that serve different purposes, if they’re pretty small 1-class “utilities”.
a package should not contain multiple groups of classes that serve different purposes, each group should be a seperate package
in general, find a decent balance between “weight” and “functional dependence”
I think that’s the main point!
The question is, what is a task, but it would be awesome to be able to opt in/out and thus replace some core features like Security Framework, MVC, AOP at some point.
Not sure whether that’s realistic but I think it helps to think in those features or capabilities as individual components and ask ourselves: What’s required to use this part outside of a Flow Application. If all those packages then end up with a dependency to some Flow Core package, we failed.
I hope that we can get rid of some of those utilities in the mid term.
E.g. Now is quite cumbersome to work with in practice… I ended up with a lot of code like this:
/**
* @Flow\Inject
* @var Now
*/
protected $now;
// ...
if ($this->now instanceof DependencyProxy) {
$this->now->_activateDependency();
}
$myModel->setSomeDate($this->now);
And then we have the issue that Now is not immutable, which turned out not to be very easy to change.
I don’t have a good idea on how to replace this, but I hope that we’ll come up with a more pragmatic way at some point.
Regarding Environment… that could also be named SwissArmyKnifeService and fortunately we already extracted most of its functionality and might be able to remove it soon.
Personally prefer not to have too many packages and rather group some stuff together. Every additional package adds overhead and boilerplate, need separate repository, versioning etc. I always dread build systems that install tons of single purpose packages, since it makes installation extremely slow. Also a composer dependency graph can get out of hand, it’s already pretty crazy for Flow and requires a downloading loads of manifests to calculate (try composer clearcachce && composer update -vvv).
Another thing I wondered about was when splitting these things into new packages, aren’t there any packages out there that could replace some of it instead? Doesn’t make sense creating additional ones for the eco system, if good ones already exist. Maybe you already checked?
I can agree with @aertmann but I try to not make this decision because of some technical problem (composer, …).
Install slow, yhea … but did you install with an empty cache really often ?
I love the NPM vision of small and even more or less empty package, that just glue some other package together.
If we have tiny package with single responsability, we can decouple them without too much effort, and share those with the PHP community, and this is a really important thing for us. If we can replace some of our code but if we can share some code, without the Flow dependencie
So much this. We have to acknowledge the opportunities of being able to work with decoupled components.
Besides there are a lot of parts in Flow that most probably won’t need changes very often, so the maintenance overhead for those would be negligible. And for the rest I’m sure we find ways to reduce the drawbacks.
I wasn’t ignoring you, I just don’t have a clear answer yet…
In general I doubt that a Utility package would help us really.
But for example a simple package for the Schema stuff would be very handy. I recently needed something like this, and there are no proper JSON Schema packages out there (We probably would have to remove some of our custom handling there though or make that configurable).
Some ArrayTools package could be useful too and it’s probably easier to extract as Utility\Arrays and Utility\PositionalArraySorter only have one dependency to ObjectAccess::getPropertyPath() as far as I can see (and maybe we can even get rid of that somehow).
Yes exactly, that’s the kind of info I wanted to hear
Thanks! Was also not specifically about you, just in general I wanted to hear peoples opinions about the specific question.
Will proceed with original plan.
Re ObjectAccess, I think a dependency on that should be fine… See
FYI: Last night @christianm and me merged the first bunch of splits (revolving around utilities). So in master a bunch of code is gone from TYPO3.Flow and will land in Packages/Libraries instead (unless you use the development collection, of course). Just so you know where it went.
but if we can share some code, without the Flow dependencie 