[eluser]n0xie[/eluser]
One of the concerns I have raised (and wiredesignz too, but people tend not to listen to him) is the fact that CI is losing much of its explicit behaviour and turning it into implicit behaviour (i.e. magic). The strength of CI for most devs is the elegance and speed CI provides. CI assumes a lot and it does not automagically tries to correct faulty devs, but instead errors out. (I would have liked to see more of that especially when it concerns naming convention: if you have a naming convention then why are all the checks in place to see if people adhere to them: just assume they do, if not they are morons).
The advantage of assuming a lot is that you don't need to check for a lot, which means (considerable) speed gains. An example is the directory structure inside the application folder: CI assumes that the config folder is there and that there is a constants file. There are no checks in play to see if they are actually there: CI won't work if they are not there, and why wouldn't they? (convention over configuration). This philosophy might lead to some disconnect with developers who don't understand the framework fully.
An example is the debate around the $_GET/Querystring support: CI assumes that whoever wants it activated knows how to setup his (web-)server and then it works fine. It doesn't lack support, it needs setting up correctly. Those are two different things. The abundant threads complaining about lack of $_GET support testify that not a lot of people understand the difference.
The latest 'fix' for this is
implicit behaviour. If the dev is not that familiar with CI and doesn't know how to setup his (web-)server, CI figures it out for them. This is all nice and dandy, but the 'cost' is that it has to figure it out on every request. Does the way your webserver work change often? Probably not. Then why does CI need to figure the same thing out every request? Why can't I tell CI: 'do it like this' and be done with it?
With Reactor, I see a lot of 'checks'. Looking at the most recent changesets I see:
- A check for the 'environment'.
- A check for the 'base_url'.
These add up and are executed on EVERY REQUEST.
All these checks are implicit: they prevent a dev from being a moron. But most of the users that need performance aren't morons. They need
explicit behaviour. They need speed. They need a framework that is ultra light, easy to extend, assumes a lot, and errors out (i.e. calls you a moron) if you are doing it wrong. Now if these were features I couldn't live without I would see the point but now I'm wondering what exactly is the gain?
The three examples I've given:
- Querystring: was working fine. Code base grew with the new checks means slower execution
- Base_url: Do you really need to check if the base_url changed between every request? How often does your base_url change? Are CI devs in the habit of moving their tld's around? Again adding code = adding execution time
- Environment: why does the framework concern itself with what environment it is on?
IF I would need this functionality, I can easily build it myself. For all the times I
don't need it, I'm stuck with useless code in my framework that only adds execution time. Why doesn't CI just assume that whatever I'm coding is 'LIVE' and force me to change that behaviour manually if it's not?
Now the performance impact of these 3 examples is negligible. It's laughable on the whole that is performance, yet it's not the examples I take issue with. In these particular cases the argument can be made for all three features ( I chose them especially because the argument can be made for them: else my ranting wouldn't have a point).
My issue is the mindset.
Reactor devs need to
weigh the 'cost' of a feature against the 'gains'. Being lazy and not taking 1 minute to set a base_url is not a good enough argument to add automated check code. At least I don't think so. If the community thinks it is, then by all means make the case. The keywords being 'community' and 'make the case'.
(it was long and my eyes were tired).
