@Aken, I know what the code does.
So what prevents a creative developer from using simple routing like so:
$route['(.*)-(.*)'] = '$1_$2';
It seems pointless hacking something into the codebase that can be solved with a little thought on the user’s part.
This would affect every instance of a dash, which is not what the mentioned functionality does. A creative developer would need to come up with a more complicated route scheme in order to achieve what literally ONE line of code does in the back-end. I don’t see how anyone can argue with that one, frankly.
Your idea of flexibility is only valid if the changes are easily understandable and will be implemented by a decent percentage of users. I do not see this happening here. Bloat occurs if code, which is never going to be used, is added to any software.
My idea of flexibility is the literal meaning of the word, which is not conditional on how a user interacts with the framework. I agree that thorough documentation is a priority, so that people will be able to understand and implement it (which I still think you should help contribute to). Who knows how often a feature like this may be used, though. Don’t let your own views of a feature completely negate its potential.
I’m personally intrigued to see if anyone comes up with an unintended-but-useful feature when it comes to the route closures. Why impede progress? The worst that I can see happening is the feature is removed, and CI developers will have a better understanding of what’s expected from the framework.
In fact adding reverse routing to CI would be much more beneficial to the majority of developers than both of these hacks.
I can’t comment on that; I’ve never had the need for reverse routes.
I am concerned also, from looking at the examples posted for the processed routes, that they are attempting to set the base business logic for an application inside the routes closures. Thus if the controller or model doesn’t also enforce business logic then altering routing will cause the application to fail. Routes should not do this, they should direct traffic not establish rules.
Default page numbers and other values should be set in the page controller, not in the routing.
Why can’t they be done in the routing? I guarantee you a lot of people have added a default page number to their routes. I’ve seen it done in people’s examples when dealing with the Pagination library, and other situations.
Copying Laravel routing methodology might be cute, but they’re missing the point entirely.
Copying Laravel was never the intention, as the author has stated in the pull request.
I can understand why you have the point of view that you do, but the impression I have is that you’re looking down at anyone with a differing opinion as flat wrong. The Reactor team has already stated their intentions to retain the feature, so rather than arguing with it, why not help make it as useful as possible? Refine the functionality, make the user guide easy to understand, etc. Help prevent the things you’re concerned about. That’s what this community is for.