Smalltalk › Pharo › Pharo Smalltalk Users

About magritte usage in pillar

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

stepharo

About magritte usage in pillar

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

CyrilFerlicot

Re: About magritte usage in pillar

Le 05/08/2016 à 15:00, stepharo a écrit :

> 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.

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.

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

signature.asc (836 bytes) Download Attachment

stepharo

Re: About magritte usage in pillar

>> 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.

>