Yes: Why should anyone want that?
Because I proposed it and I propose only cool things. nods in agreement with himself
my head is still spinning in 1.0 land :P .... maybe
@groundup can offer some advice :D (I do think its cool)
And what problem are you hoping to solve by switching to oop? Or what will this let you do that you can't do now?
None in particular.
It's a way to code, not a way to solve problems (well, someone may disagree with that statement, but not a problem in the current discussion).
BTW, it's not "switching", is continuing moving towards.
Heck if I know.
Otherwise I wouldn't have opened a topic with subject "experiments". I saw a pattern that looked interesting, used by one of the most famous php framework out thereand that fitted Elk's structure. I tried to use it and asked for opinions. That how my brain works. :P
Back to the general answer.
Elk has already some oop elements (there are classes around :P), but as far as I can say they are not really organized, or at least they do not look organized to me. Many of them are singleton, 1, 2, 4, 5 singleton classes hanging around (few multiton as well), they may or may not look nice (I personally tend not to like them, but it's just personal preference I guess).
Now, what I did above is not much different: a "big" singleton with several instantiated classes attached somewhere inside of it.
One of the "annoyances" that it would let me solve is the fact each time I need the database, I have to call a function to grab the object. Any time I need to add a layer I have to call another function just to have the object. Same goes for errors, and likely other things now or in the future.
Bad design? Possible. But improve and hopefully fix it is the the reason "we" are here.
Another annoyance that oop would help reduce is the need to always find new names different from those already existing and always longer and less meaningful (yes, this should be solved by aggregating functions and reuse code, but not always is easy, not always is possible).
Thanks for mentioning me. Glad I saw this. Singletons aren't really good practice. Not saying that they can't be used, but generally you should try not to use them.
This is a Dependency Injection Container (DIC) and I think the best one out there is Pimple. It is small, light, and extensible. It also doesn't use any singletons.
Here's the problem with your example: what if you wanted to change the database there to something else? You'd have to rewrite it. If you injected the database object in to that class, you wouldn't have to rewrite anything. You would just inject a different database. Simple. You would use a database interface to ensure it won't break in the methods. Another problem with that class is, what if you want to extend it and add more properties and methods? You'd have to change what is instantiated in the bootstrap file. This is another case where Pimple, with its variables, works best.
Why?
There is a config setting that allows to change the database to whatever wanted, isn't that enough?
Or are you suggesting each class should be allowed to use a different "database" system "on-the-fly" while executing?
hmm...
You are probably looking too far away than I did at that point.
Or maybe we are giving the Elk class two different meanings: to me the Elk class is what "initialize" what Elk needs, it is probably what you call the "bootstrap file".
Dunno, I have to look more into it.
Yeah, say I have a class called JoshDB. I'd either have to change the database configuration or change every call to its methods.
That Elk_Settings class would have a constructor like
public function __construct(DatabaseInterface $db, array $settings)
Though, you would store that in your DIC. This way, you only
inject what you need in the class. It makes it much more testable as you can inject mock objects.
Your bootstrap file states what $app->db is. With
Pimple (http://pimple.sensiolabs.org/), it is a lambda function.
I'm trying to see the use case here: you want to use a database different from the one configured. Why? (It's a genuine question, to me the application uses the database it is configured to use, it's kind of difficult for me at that point to think about cases where you want to initialize the application with a MySQL database and want to use Postgre for certain actions... well, I could see some, but in all the cases it would be a completely different database (for example a WordPress) that will not likely use anything from Elk, so entirely custom code anyway.)
You don't even have to think about switching the engines. Think about switching from a master to slave or you want to send some stuff to another server.