Donate
We have been asked many times about why we do this, or why we didn't do that. Well, we have really good reasons for everything we do. Let's start by going over our core philosophy:
Simple, Powerful, Lightweight and Fast.
Basically, this means we need to keep everything as simple to use as possible, while making it as powerful, lightweight (low memory usage) and fast as possible. So, keep these 4 things in mind as we go through.
Note: In some cases simplicity must be forgone to ensure it is lightweight, fast or powerful (or all 3).
It is also important to note that just because not everyone understands, or knows how to use a certain pattern, or PHP feature, does not mean we won't use it. There are certain things that we do, that you will not like or know how to do at first...but you will get the hang of it, and be better for it.
Anyway, lets get on with it.
We get this one a lot: "Why is everything static?" or "Why do you use factories everywhere?"
First, let me start by saying this: Not everything is static, and in a lot of cases, there is just a static interface to a non-static backend (e.g. the Session class).
To put it simple: it uses less memory. If you don't have to instantiate an object, you don't have to reserve memory for that object. This also makes it easier to use. There is no reason to instantiate an object just to call, what is essentially, a helper function.
As for factories...there are 2 very simple reasons for this: A) It allows method chaining off the constructor. B) Sometimes we want to do pre-processing prior to giving you the object. The second reason is used heavily by a lot of libraries to allow "Drivers" for things (e.g. when you call Session::factory() you actually get a driver class back...like Session_Cookie).
This is another one we often get: "Why are all the core classes so dependent on each other?" or "Why didn't you use Dependency Injection?"
This answer is both simple, and complex at the same time. Basically, it allows us to stick to our core philosophy. Dependency Injection (no matter how well you implement it) leads to slower, more bloated, harder to use code. So obviously, we didn't want that. Being coupled allows our classes to be fast and simple. No need to tell it (for example) which Config class to use...it will just use it.
So let's look at what some of the biggest dependencies are...take any of these classes out and the framework falls apart:
There are other ones as well (such as Security) but those are the 6 major ones. Even though they are highly dependent, they are dead simple to extend or even replace all together, without touching a single core file.
So basically, we chose Configuration over Convention because, well, we can't read people's minds. We could pull the "These are the conventions, deal with it", however, we prefer people actually use our framework. Simple as that.
Well, to be honest, we don't. We don't even use many of them. We use a derivative of the Singleton, called the Multiton. A Multiton is just what it sounds like...multiple singletons. The way we use it is so that the libraries can keep track of it's instances. You just give the instance a name, then request it again later. This is so that you can use the same instance of a class in multiple scopes, without having to pass the objects around.
We do think about and debate all decisions like these. We did not pick these out of pure randomness, they are all to make the experience of using the framework better.