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.
