On Fri, 20 Apr 2007 21:26:33 +0100 Andy Armstrong <[EMAIL PROTECTED]> wrote:
> I agree that it's not massively general - but you could use it to
>
> * generate fixed width fields
> * truncate reals to ints
> * specify the number of decimal places
On further thought, that all sounds very specific to numbers, and hard to
generalise. It also breaks the symmetry of operations, as I have already
noted.
Also, someone else objects by private email that:
> Surely you've just reintroduced what your were trying to eliminate in
> the first place: separate languages for describing patterns and for
> describing formatting.
This does indeed seem to be the case. If you wanted full formatting
control, you might as well go with two separate strings; one for pattern
capture, one for formatted interpolation.
> Given a sprintf format, it's easy to work out what the pattern for it
> would be, so can the pattern be optional?
This is equally difficult in this direction.
Consider for a moment a cut-down case of UK Postal Codes, which would
match a regexp
${POSTCODE:[A-Z][A-Z][0-9] [0-9][A-Z][A-Z]}
Were we instead to provide just a printf format for this, the only one
that comes to mind is '%s'. Hard to say how we'd ever know to generate
that specific pattern from there.
No, I think at this point we have to appeal to the core reason for
creating this module in the first place; namely, that it is
bidirectional. Parsing a string into variables, or interpolating the
variables back into a string. Both can be done within one object,
symmetrically. To introduce something that breaks that symmetry
effectively removes the requirement that it be done within one object, at
which point one might as well use two separate objects for each individual
operation.
--
Paul "LeoNerd" Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
