>Building a tr/// table is much much simpler and much less work than >compiling a regex, but we don't make people write > eval " \$s =~ m/$pat/ " >when they want to interpolate a string into a regex at run time. >Instead, we take care of it transparently. tr/// could easily be made >to work the exact same way. One thing to be careful of there is thread safety. You can't hand the data off the syntax node (the one with the tr op on it), because tr/$foo/$bar/ wouldn't work for several threads in it at the same time then. --tom
- Re: RFC 165: Allow variables in a tr/// Stephen P. Potter
- Re: RFC 165: Allow variables in a tr/// Mark-Jason Dominus
- Re: RFC 165: Allow variables in a tr/// Nathan Wiger
- Re: RFC 165: Allow variables in a tr/// Tom Christiansen
- Re: RFC 165: Allow variables in a tr//... Nathan Wiger
- Re: RFC 165: Allow variables in a tr/// Tom Christiansen
- Re: RFC 165: Allow variables in a tr/// Mark-Jason Dominus
- Re: RFC 165: Allow variables in a tr//... Tom Christiansen
- Re: RFC 165: Allow variables in a... Mark-Jason Dominus
- Re: RFC 165: Allow variables in a tr/// Stephen P. Potter
- Re: RFC 165: Allow variables in a tr/// Tom Christiansen
- Re: RFC 165: Allow variables in a tr/// Stephen P. Potter
- Re: RFC 165: Allow variables in a tr/// Piers Cawley
- Re: RFC 165: Allow variables in a tr/// Bart Lateur
- Re: RFC 165: Allow variables in a tr/// Tom Christiansen
- Re: RFC 165: Allow variables in a tr//... Stephen P. Potter
- Re: RFC 165: Allow variables in a... Tom Christiansen
- Re: RFC 165: Allow variables in a tr/// Eric Roode