in reply to Text::xSV
|
---|
Replies are listed 'Best First'. | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Re (tilly) 2: Text::xSV
by tilly (Archbishop) on Apr 17, 2001 at 04:17 UTC | |||||||||||||
Besides which I would not encourage the proliferation of file formats which are by design not extensible or self-documenting. See the note in the documentation that I provided about exactly that. Fixed width file formats are not exactly on my hit parade of great ideas to encourage. An incidental question. Even if I did want to use fixed width file formats, what is your value add over the better-known pack and unpack plus Perl's native support for formats? Perl started life dealing with lots of ASCII reports and has quite a few now little-used facilities for doing just that. | [reply] | ||||||||||||
by princepawn (Parson) on Apr 17, 2001 at 04:38 UTC | |||||||||||||
Regarding use pack and unpack instead of Parse::FixedLength, Text::FixedLength, and Text::FixedLength::Extra, if you read "Data Munging with Perl", the answer would be none, because he did not mention the FixedLength module set in his book, but instead focused on pack and unpack. I think pack and unpack are excellent for implementation of fixed-width data processing, but in terms of making a human-level description, a higher level interface is needed. For example, let's say I have this:
Here is a high-level description that one could expect a data-entry expert to convert the english above into: and to turn that into the programmatic representaiton of Parse::FixedLength is a one-step transformation: And then the script which plugs into the data description is quite clean, with no low-level Perl pack/unpack: And of course, internally Parse::FixedLength can implement it's high-level API with pack, unpack, or sprintf as need be. | [reply] [d/l] [select] | ||||||||||||
by tilly (Archbishop) on Apr 17, 2001 at 08:35 UTC | |||||||||||||
I think you are overestimating the difficulties of using pack/unpack, underestimating the abilities of the people who are likely to deal with the format and overestimating again the naturalness of interfaces you have grown for other people. You have also discounted entirely the cost of learning your interface (particularly if someone doesn't know any Perl) and there is a loss of flexibility. You see, abstractions require domain specific knowledge, and they are only worthwhile when they either significantly simplify things, or when you will have the opportunity to use that information over and over again. Neither appears to be the case here. Plus looking at your example snippet I have to wonder at the amount of pass by reference magic you seem to be fond of. That is not the kind of API I like to write or use. In short, I don't deal with a lot of fixed position formats. But if I found a need to, I would spend time getting more familiar with perlform and Perl's other native facilities before reaching for these modules. | [reply] | ||||||||||||
by Anonymous Monk on Jul 07, 2005 at 05:35 UTC | |||||||||||||
| [reply] |