...

Hi cyril

I would like to discuss with you about the use of magritte in pillar for configuration.

In particular I do not understand why accessors are not simply generated and stored as part of the code.

It will avoid to have defaultExporters: treated as an unknow message.

activate super activate. self optionAt: 'to' ifPresent: [ :subconf | configuration defaultExporters: {subconf} ]. self optionAt: 'path' ifPresent: [ :path | configuration outputFile: (RelativePath from: path) ]. self parseInputFile. self export. self exitSuccess

if you are on chat somewhere let me know.

Stef Hi Stéphane,

In Cocoon before we got 3 methods by parameter of the configuration: - the getter - the setter - the default value

In pillar, there is a lot of parameters, so in the end we had a class with *a lot* of methods and it was hard to use. Why once they are defined this is done. In that case we can have a simple method defining these extra methods if you mean that this is tedious to write. I do not see the gain to use a dynamic tricks to replace something that can be solve purely statically.

Now in Cocoon for a parameter you just have to define one method: the description. The configuration will use DNU in order to check the descriptions to invoke the right one.

I think that both ways have pros and cons. If it has to be change it should be pretty easy.

I think that using DNU should be an exception. Because it breaks static tool and we cannot look for implementors and it always gives a strange feels.