I've just seen a #programming pattern in #PHP where a method could return two lists of things. Instead of doing that, it takes as a parameter a callable, and passes the two lists to the callable. Instead of:
[$a, $b] = getLists($param);
// Act on both lists.
we have:
$callable = function($a, $b) {
// Act on both lists
}
actOnLists($param, $callable);
@joachim Imposing a higher-order function where it just complicates things without any gain would (if at all) be an anti-pattern.
But it might be that the implementation of actOnLists is lazy w.r.t. the lists, which would improve performance in an otherwise strict (= eager) language in case not the whole lists are needed.
(Assuming getLists isn't a mere lookup but would have to actually produce (build / compute) the lists and their content.)
@das_g Thanks for the analysis! actOnLists() isn't lazy, but it does need to make queries. Further complexity is that it actually retrieves more than one pair of lists. I imagine the higher-order function pattern was written here to avoid returning an array of arrays, or writing a value object class for just this one purpose. I'm not sure how much of a gain I consider that though, as I find the current pattern hard to get my head round.
@alessandrolai@Girgias If there is I haven't found it, yet. @Girgias suggested rule sense like where it belongs. What I meant to say is THAT RULE doesn't seem to care what order readonly comes.
@nyamsprod as other have said, definitely a BC for A due to class removal. And due to the inverse relation, you don't even have an easy migration path (like with a plain class_alias or an extension)... 😔
@alessandrolai I have an easy way out I can bump package A to the next major and keep B in it's current version and move the class there effectively embracing the BC break BUT it makes my monorepo ugly to work with until I bump package B to the same version as package A and I need in the meantime fin a good git-split tool able to handle 2 majors release ... that's the complex part