RFC: Core config helper class

RFC: Core config helper class

by Adam Olley -
Number of replies: 13
Picture of Core developers Picture of Plugin developers

So I was playing with the idea of a core helper class for accessing config:

https://github.com/aolley/moodle/blob/core_cfg/lib/classes/cfg.php

The idea is that instead of declaring "global $CFG;" and then using the $CFG variable in your code, you could just call:

\core\cfg::core('somesetting')

I also threw some wrappers for the other core config functions in there so that you'd be interacting with config from the one place.

Pros:

  • Config related calls are brought together into one place.
  • Don't have to remember to declare "global $CFG;" (or remove it after you stop using CFG in a function), and helps avoid silent config failures when 3rd party code (or any code for that matter) forgot to global $CFG
  • Encourages developers to use less globals
  • Moves configuration management into a nicely namespaced class rather than a collection of global functions

Cons:

  • As pointed out (quite rightly) by Eloy, its already covered by the core get_config function. Calling "get_config('core', 'somesetting')" achieves almost the exact same result (when a setting simply doesn't exist, get_config returns false, where an unset $CFG value results in null (and a php notice).
  • For the same reason as above, you get some of the pro's above just by using get_config.
Average of ratings: Useful (1)
In reply to Adam Olley

Re: RFC: Core config helper class

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I am sure if we were starting today, we would not use a global $CFG.

However, Moodle has used global $CFG since forever. Everyone understands it, and accessing properties of an object is much faster than a method call. (And yes, on occasion, it makes a difference. MDL-39474.)

More to the point, there are much bigger problems in the Moodle code. If you want to make Moodle better, I would suggest finding some legacy JavaScript and moving it into an AMD module. Or finding some part of the system that does not currently use renderers or templates for output, and converting them.

So, interesting intellectual exercise to think how this could be done better, but almost certainly not something we should change, since when you change an API like this you make lots of additional work to update all core code, and even more work for all the plugin developers to update their code.

Average of ratings: Useful (2)
In reply to Tim Hunt

Re: RFC: Core config helper class

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers

Hi Tim -

You said:

"I would suggest finding some legacy JavaScript and moving it into an AMD module."

Can you point interested people to some information on what needs to be done / how to do this? Tracker items, forums and/or moodledocs?

mike

In reply to Mike Churchward

Re: RFC: Core config helper class

by Dan Poltawski -
Can you point interested people to some information on what needs to be done / how to do this? Tracker items, forums and/or moodledocs?
I'm not sure there are tracker issues for it because if nobody is planning on working on it it'll just sit there gather dust. 


But first step would be to search for YUI2 and get rid of any code using that smile In fact, I just found there is an issue for that which has gathered associated dust (now needs to talk about AMD rather than yui3). MDL-36373 

In reply to Dan Poltawski

Re: RFC: Core config helper class

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers

Hi Dan -

I figured that might be the case, but thought I'd ask anyway. Is there an example area where YUI2 was removed from core and replaced with AMD? That would provide a place to at least see what it was and what it now is. That might provide enough information to do more of the same.

mike

In reply to Mike Churchward

Re: RFC: Core config helper class

by Richard Oelmann -
Picture of Core developers Picture of Plugin developers Picture of Testers

Renderers is the other big one, with the lack of a renderer for the login page being one that comes up frequently - I don't know the tracker number and I'm heading off to a meeting (5 mins ago ;) ) but it should be there to find.

In reply to Mike Churchward

Re: RFC: Core config helper class

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers

Hi Dan / Tim -

Just checking once more if either of you know of an example where YUI2 was removed and replaced with AMD in core. Again, this is to help with anyone who wants to pick up the suggested improvement work.

mike

In reply to Mike Churchward

Re: RFC: Core config helper class

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I don't know of any good examples.

git log --diff-filter=D --name-only -- '**/module.js'

will show all the commits where a file called module.js was removed from the code. Old JS often lived in files called that.

git log --diff-filter=A --name-only -- '**/amd/src/*.js'

Will find commits where a new-style AMD module was added.

I am not sure if any of those are useful examples.

Well, https://github.com/moodle/moodle/commit/1f0f413187e9ca60b311f4003c25b9bf9ca617e3 might do, but in that commit, changing the JavaScript was only part of a larger change, and the new JavaScript still uses YUI.

In reply to Adam Olley

Re: RFC: Core config helper class

by Russell Smith -

I would say moving from an stdClass to a proper class would help with development and support.  Auto completion would tell me useful things and some properties could be made read or write only.  Also inventing new random names/properties could be stopped.  But that is replacing $CFG with something else, not doing what's proposed here.

If we are serious about removing $CFG, then dependency injection is more the answer than taking an old global mechanism and replacing it with a new global mechanism.  Using dependency injection also let's some testing be a bit easier, allows classes to be created with config different than $CFG if required or you can adjust the config at class creation rather than on each evaluation.  The debug developer case Tim cited is a good example.  Should we just have passed the debug flag to a class constructor.  I know this is not possible in the pure functional code but it does seem a good idea for OO parts.

I think it better to try and use OO more and dependency injection to get better outcomes.  Are there other changes to $CFG that could support that?

Average of ratings: Useful (1)
In reply to Russell Smith

Re: RFC: Core config helper class

by Adam Olley -
Picture of Core developers Picture of Plugin developers

TH: "since when you change an API like this you make lots of additional work to update all core code, and even more work for all the plugin developers to update their code."

Which is why I was suggesting it as a simple helper class you could choose to use if you wanted to and not suggesting replacing $CFG's existing usage anywhere. But as Eloy mentioned, get_config() does pretty much provide you pretty much the exact same main benefit - not needing to declare global $CFG.

As you've pointed out, config isn't a terrible mess or anything (compared to legacy code everywhere that needs updating) and isn't in need of a massive overall any time soon.

==

RS: "But that is replacing $CFG with something else, not doing what's proposed here."

I had considered something like that, but figured it'd be way too far into the "too risky" territory that it'd scare people right off. I was thinking of having setup transform the config.php's CFG into some config class. All uses of CFG in moodle would then be using it, and you'd be able to build on whatever helper functions you wanted onto that proper class.

In reply to Adam Olley

Re: RFC: Core config helper class

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Making two different ways to do the same thing (access config) just makes Moodle code less consistent and harder to understand. Please, don't do it. As I say, there are real problems in the Moodle code that are much more worthy of your time.

In reply to Tim Hunt

Re: RFC: Core config helper class

by Dan Poltawski -

I'm afraid i'm with Tim on this one, there aren't enough benefits to justify it.

 (And to be be clear - this is the sort of thing we are really bad at doing in Moodle and need to do less of).

Average of ratings: Useful (1)
In reply to Adam Olley

Re: RFC: Core config helper class

by Adam Olley -
Picture of Core developers Picture of Plugin developers

Consensus reached: get_config provides the desired benefits already, no need to pollute the global space further with more ways to do the same. Thanks for the input everybody smile