wyri, 5 months ago

So full into #PHP it is then: https://toot-toot.wyrihaxim.us/@wyri/111654449355589397

Especially when looking across the networks #PHP is the clear winner: https://twitter.com/WyriHaximus/status/1740119059285561846

Been working on this slowly over the past few days and honestly #PHP is the way to go. Other formats are nice, but #PHP allows for so much flexibility 💗 !

dseguy, 5 months ago

@wyri I think you could also consider INI, TOML, JSON.

I also have that kind of question on a regular basis. This is where the feature (read a config file) and the format (well... all of those above) have to be decoupled.

There could be a package that handle all those formats (modular), apply some validations (optional) and deliver a pre-defined class. Also, write to those formats.

That would be a very useful package.

jaapio, 5 months ago

@dseguy it should be possible to build this using symfony/config. They support a decoupled config definition in php, you just need to write a parser @wyri

wyri, 5 months ago

@jaapio @dseguy Not opposed to it, as long as I can do the nested properties in INI as I can in PHP, YAML, and JSON.

dseguy, 5 months ago

@wyri @jaapio Switching that way is an important organic evolution, that follows the maturation of the code.

And then, the rest is a matter of decoupling from preferences. Such package would read any valid format, until that format doesn't fit requirements.

jaapio, 5 months ago

@dseguy @wyri in theory any format could fit. As long as the parser outputs the same AST/DSL.

wyri, 5 months ago

@jaapio @dseguy Hmm the symfony docs are rather scarce. Rather go either full PHP or full PHP with support for YAML and JSON as alternatives hydrating using https://github.com/EventSaucePHP/ObjectHydrator into the same PHP class tree.

jaapio, 5 months ago

@wyri @dseguy yeah they see this as advanced usage, so you need to dig in the code. I disagree with that, but I understand that they have to limit their time on docs.

wyri, 5 months ago

@jaapio @dseguy Yeah no, so it's an unsupported feature IMHO then. I'll stick to this for now then:

jrf_nl, 5 months ago

@wyri XML ;-) (or json is needs be)

Very much dislike Yaml as spaces having meaning is the road to insanity.

Also not keen on PHP for config files as I like the separation between config and code and PHP config files break that premise.

heiglandreas, 5 months ago

@jrf_nl @wyri OTOH saving on parsing some "other" language into PHP code and being able to use an IDEs code-completion for the language are positive sideeffects for configs in PHP...

just sayin... 😁

NanoSector, 5 months ago

@heiglandreas @jrf_nl @wyri You can get pretty much the same effect with XML and a well defined schema though, IDEs should be able to complete those just fine

heiglandreas, 5 months ago

@NanoSector Absolutley! XML was not part of the original poll. I'm very much in favour of XML. And if not PHP, then please XML!

/cc @jrf_nl @wyri

wyri, 5 months ago

@heiglandreas @NanoSector @jrf_nl @gmazzap Ultimately it all has to be hydrated into PHP as the configuration passed around is a nested object tree. YAML and JSON can be mapped into that., XML as well I'm assuming. Doing it directly in PHP allows for more flexibility and more DRY code/config, when things get complicated. Attached WIP PHP and YAML config files.

image/png

gmazzap, 5 months ago

@jrf_nl @wyri I'm very much for config in PHP. If you support a "config.php" file or so, separation exists, but the boost in flexibility is huge.
If the file has to return an array, what happens in that file is up to you. As an example, functions or vars can avoid duplication in similar parts. And if you document the expected array, you can even have static check via Psalm/Phpstan.
Not to mention freeform comments.
And there're many existing libs for type-safe object hydration from array.