If one is designing from scratch, then you are right,
fixed-width is not extensible nor self-documenting. But
I know that Valley Media, the company who does fulfillment
for Amazon.com and CDNOW and some other people I have worked
for, does use fixed-width format and they have too much
technology behind it too change in midstream. I would be
surprised if they are the only such place using this
admittedly inferior format.
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:
field name |
field width |
justifiction |
numeric? |
catalog id |
12 |
L |
no |
price |
6 |
L |
yes -- with 2 decimal places |
Here is a high-level description that one could expect a
data-entry expert to convert the english above into:
catalog_id = '12L',
price = '6L*2'
and to turn that into the programmatic representaiton of
Parse::FixedLength is a one-step transformation:
package Business::Logic::Orders;
our $line_data = [
{ catalog_id => '12L' } ,
{ price => '6L*2' }
];
1;
And then the script which plugs into the data description
is quite clean, with no low-level Perl pack/unpack:
###
open D, 'data-file.dat';
while (<D>) {
Parse::FixedLength::Parse(\%line_parse, $Business::Logic::Orders);
DBIx::Recordset->Insert({ \%dsn }, \%line_parse} );
}
And of course, internally
Parse::FixedLength can
implement it's high-level API with pack, unpack, or
sprintf as need be.