2023/06/04/config classes

Codeblog 2023/06/04 config classes 2023/05/01 DataPorts redesign 2022/07/21 FutilityCloud process design 2022/08/14 Windows joke I wrote in the late 1900s (on TootCat) 2022/07/21 render-dispatch rubberduckery 2022/07/20 comments on The Home Computer Generation 2022/07/18 layout-event rubberducking 2022/06/24 event-object as output container: the consequences 2022/06/23 event-object as output container: the revision 2022/05/30 more data-class rubberducking 2022/05/20 rubberducking about data classes 2022/01/15 standard CV data format 2021/12/17 The Great Data-Class Restacking 2021/11/25 PHP documentation gripe 2021/11/24 things you can't do in PHP 2021/11/23 PortBank refactoring part 2 2021/11/22 PortBank refactoring part 1 2021/11/08 data objects refactoring 2021/11/05 notes for event-system burndown 2021/07/31 a code mystery 2021/05/31 new PHP wishlist item: first keyword 2021/05/28 a kluge using abstract methods 2021/03/21 PHP wishlist 2020/12/04 (notes) 2020/10/30 (notes) 2020/10/29 (notes) 2020/10/28 (notes) 2020/10/27 (notes: Dovecot on cloud5) 2020/08/29 MediaWiki SpecialPages 2020/08/25 The Plex API 2020/06/12 Ferreteria: thoughts on the Wikcess/flex-data system 2020/04/23 Ferreteria: quick notes on a design issue 2020/04/22 Ferreteria: some thoughts on apps vs. frameworks 2020/02/10 job application (yes, I actually sent this in)

I just figured out a thing which had been kind of muddy to me up to now, despite wrangling with it for a couple-few years.

Addendum 2023-10-05: I've turned this post into a couple of reference pages: conventions/code/patterns/config, conventions/code/patterns/singleton

Background

I use classes for config stuff – unlike what Laravel does with array-per-file in a config folder, or what MediaWiki does with LocalSettings.php and global variables.

This has multiple benefits, of which the main one is probably that you don't need any special loading mechanism and can refer to a config item from anywhere by invoking the class.

Now... this can be done either:

• as a dynamic class with a singleton method that auto-creates the object as the invoking class – so to access config params, you go something like Config::Me()->ParamName()

...or...

• as a static class, where you just access the params directly like Config::ParamName().

The static method is easier on the brain, but it doesn't allow for having descendant classes that override defaults or define abstracts...

(Oh, that's another benefit of a class-based config: you can do abstract methods for things that need to be filled in by specific apps or deployments.)

...because then the code has to know what class to use, and even if you somehow gently guide the endcoder into correctly naming their final config class, this greatly restrains flexibility. Using separate config classes for separate areas of concern imposes that same additional documentation/constriction overhead for each class you want to have, for example.

Using a dynamic class, on the other hand, means that the endcoder can call their config classes whatever they want (or even have multiple alternates for different situations), as long as they make sure to instantiate the classes they want to actually use before any other code needs to access configs. The endcoder's config-object then becomes ::Me(), which is what all the other code refers to for the actual config methods.

Realization

Actually, I'm not sure it's significant as I thought, now that I spell this all out... and I'm out of writing time for the moment.