Include/Import config

[nickl-]

What about include config considered a dependency which may have values referenced and thus should be processed first. The result will be a combination of settings perhaps in the form:

$result = $config + $config_include_last + $config_include_n_desc + $config_include; 

Allowing each to overwrite settings from the previous.

Now we just have to decide what an import/include looks like. Perhaps also a header comment in order to use the same key

; import defailt.ini

or we could use an array

import = [default.ini, production.ini, app.ini]

I would rather prefer a list underneath each other though

import = $import:path/to/default.ini
matters = $import:path/to/matters.ini
not = $import:path/to/not.ini

Hmmm little weird... thoughts?

[alganet]

I've been using a pattern for a quite long time:

<?php
$configLoader = new Container('loader.ini');
$config = $configLoader->config;

[config Respect\Config\Container]
loadFile[] = [default.ini]
loadFile[] = [production.ini]
loadFile[] = [app.ini]

Works pretty well! Perhaps we could institutionalize this pattern. Some kind of:

[this]
loadFile[] = [app.ini]

[conn PDO]
etc = ...

[nickl-]

Yes of course an array! Why didn't I think of that.

@alganet Have you given overwriting preference any thought? I guess we have two options top-down or bottom-up, unless there are something like arrays which I'm not seeing. =)

Dependencies are a non issue as all the values will be loaded before they ever become required, iow the order does not impact dependency unlike overwriting which will require a definitive preference where conflicting properties are found.

[alganet]

I'm pretty sure the Container only works from top to bottom. It can handle some missing variables in the way, but I didn't tested with large links between objects missing (which is similar to reading from bottom to top).

Config is pretty fragile. It's magic comes from two limitations: it follows the INI data structure which has limited deepness and it depends on the order of declaration. This limitations also work as reassurance. We can infer a lot more from a limited container and provide runtime flexibility instead of static flexibility. That's why it's code is so hard to change and at the same time so powerful.

[augustohp]

:blush: Just remembered what the issue #23 with "Better entropy solver" had to do about: When we load multiple files, we need to load them in the correct order or declare them in the right order. The issue was to solve that kind of problem, seeking for dependencies and the container (ini) whom had more entropy (dependencies) would be loaded later. Does that ring a bell to you @alganet ?