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" } }
Of course this highly depends on the nature of your data, like
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! :)
NB: this approach is also useful when handling only one input format, because you can cleanly separate code, hence much better maintain it.
°) 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
In reply to Re^3: Contextual find and replace large config file
by LanX
in thread Contextual find and replace large config file
by Veltro
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |