Re^2: Contextual find and replace large config file

Yes, I was actually aware of that error, since you mentioned it I edited the OP

Not strictly necessary to provide example code (plus others have already done so), I am just trying to redesign some code and trying to find a different approach. So your generic answer is welcome of course

The only thing is what you mean with your first suggestion (separate parsing...semantic logic). What do you mean with that? Do you mean parsing and gathering data first and then split the processing of that data into different function blocks or something else?

Thanks, Veltro

Comment on Re^2: Contextual find and replace large config file

Replies are listed 'Best First'.
Re^3: Contextual find and replace large config file by LanX (Saint) on Jan 03, 2019 at 14:49 UTC
> (separate parsing...semantic logic). What do you mean with that? Your two examples seem to hold the same information (semantic) while having different format (syntax). So better write parsers for the different formats which "cache" them in an intermediate format. These parsers should be ignorant about the meaning just concentrating on correctness. The semantics - the meaning of the data - could be handled by one central module which only operates on the intermediate format. This module could be re`use`d for all formats. A possible intermediate format could be nested hashes `$cache = { ObjectType1 => { Param1 => 8, Param2 => "SomeText", NestedObject => { Param1 => 3, Param2 => "SomeText" } }` [download] Of course this highly depends on the nature of your data, like does order matter? are repeated elements allowed? Using nested arrays may be better then° And after transforming your data you can also have emitter modules to write them into a new out file. Like this you are even capable to transform between different formats, or add new ones. HTH! :) edit NB: this approach is also useful when handling only one input format, because you can cleanly separate code, hence much better maintain it. update °) or a mix of hashes and arrays. Or even using Perl objects blessing elements into different "ObjectTypes", ... Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Contextual find and replace large config file
by LanX (Saint) on Jan 03, 2019 at 14:49 UTC

> (separate parsing...semantic logic). What do you mean with that?

Your two examples seem to hold the same information (semantic) while having different format (syntax).

So better write parsers for the different formats which "cache" them in an intermediate format. These parsers should be ignorant about the meaning just concentrating on correctness.

The semantics - the meaning of the data - could be handled by one central module which only operates on the intermediate format. This module could be reused for all formats.

A possible intermediate format could be nested hashes

$cache = {
    ObjectType1 => { 
        Param1 => 8,
        Param2 => "SomeText",
        NestedObject => { 
            Param1 => 3,
            Param2 => "SomeText"
        } 
}
[download]

Of course this highly depends on the nature of your data, like

does order matter?
are repeated elements allowed?

And after transforming your data you can also have emitter modules to write them into a new out file.

Like this you are even capable to transform between different formats, or add new ones.

HTH! :)

edit

NB: this approach is also useful when handling only one input format, because you can cleanly separate code, hence much better maintain it.

update

°) or a mix of hashes and arrays. Or even using Perl objects blessing elements into different "ObjectTypes", ...

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice}

[reply]
[d/l]