Skip to main content ↑ ↓
Topic: Experiments (Read 3769 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Experiments

Recently I was playing with Yii (no, don't worry I'm not suggesting to base Elk on that ... even though... :P), and since Elk is still very young and has several things that do now allow easy switch between the current model and "full-oop", I started experimenting with something similar:
https://github.com/emanuele45/Dialogo/tree/app
https://github.com/emanuele45/Dialogo/compare/elkarte:development...app?expand=1

The crux is the Elk class:
https://github.com/emanuele45/Dialogo/blob/app/sources/Elk.class.php
intended as the "application", the singleton that should encapsulate all the stuff we need (common functions, settings, the database object, template layers, etc.) and that can be used like this:
https://github.com/emanuele45/Dialogo/blob/app/sources/ElkSettings.class.php#L73

Opinions?
Bugs creator.
Features destroyer.
Template killer.

Re: Experiments

Reply #2 –

Because I proposed it and I propose only cool things. nods in agreement with himself
Bugs creator.
Features destroyer.
Template killer.

Re: Experiments

Reply #3 –

my head is still spinning in 1.0 land :P .... maybe @groundup can offer some advice  :D (I do think its cool)

Re: Experiments

Reply #4 –

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?

Re: Experiments

Reply #5 –

Quote from: scripple – And what problem are you hoping to solve by switching to oop?
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.

Quote from: scripple – Or what will this let you do that you can't do now?
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 there[1]and 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[2], 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[3].

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).
1 I'm not discussing bloatedness of frameworks or if frameworks are a good thing to use or not. There are people using them, so it may not be that bad (no, windows is not that bad either), and as I wrote I'm not suggesting to use a framework or not. ;)↵
2 That is not bad thing, is not a good thing, is just a way to use code↵
3 Except I'm here just to mess with code and people. :P↵
Bugs creator.
Features destroyer.
Template killer.

Re: Experiments

Reply #6 –

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.

Re: Experiments

Reply #7 –

Quote from: groundup – 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.
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?

Quote from: groundup – 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.
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.
Bugs creator.
Features destroyer.
Template killer.

Re: Experiments

Reply #8 –

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

Code: [Select]
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, it is a lambda function.

Re: Experiments

Reply #9 –

Quote from: groundup – Yeah, say I have a class called JoshDB. I'd either have to change the database configuration or change every call to its methods.
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.)
Bugs creator.
Features destroyer.
Template killer.

Re: Experiments

Reply #10 –

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.