On Sun, 2001-11-04 at 14:31, Todd Gillespie wrote:
> On Mon, 5 Nov 2001, Sean Middleditch wrote:
> 
> > dangerous.  Honestly, using eval at all is merely poor code design.
> 
> Bah.
> 

:P

> > The reason your problem was never solved well before was because regex
> > was depended on.  Regex's can't do everything.  And eval wil often do a
> > lot more than you want it to.
> 
> You don't know the power of the dark side of regexes.

Would one rather muck with regex's for 5 hours to get the task done, or
spend 20 minutes tops writing a simple parser?

> 
> > The best bet is to scan the string character by character.  Keep a
> > seperate string that you add each scanned character to.  When you hit a
> > , copy the new string onto the end of your array.  If you hit a \, then
> > set a temporary "escape" flag that makes the next character added to the
> > scan string no matter what (and then unset the escape flag).  If you hit
> > a ", then set a quote mode that causes all scanned characters until the
> > next " to be added to the scan string.  You can do the same with ', if
> > you want, but be sure to use a different escape flag, so ' won't
> > unescape a string started with ", and vice versa.  Some string commands
> > will make the search much faster (find first occurance of '"\, ), since
> > they are run in C.  This will be 100% robust if coded right (it will
> > even handle your above mentioned problem with ', , ,'), will likely be
> > faster than a regex (depending on regex engine), and will be perfectly
> > safe and sane, unlike a poor eval() implementation.
> 
> I just don't agree that the proper thing to do is to encourage everyone to
> write their own parsers for each task.  Most of us are trying to move
> *away* from C-style per byte mucking.  Certainly Albert shouldn't ignore
> his SAFE flags, but that's hardly grounds to abandon generalized parsing
> engines.

If there were an effective generalized parsing engine, it wouldn't be
necessary.

> 
>