On Tue, 8 Aug 2000, Michael Mathews wrote:
> Dan Sugalski said:
> > > > * Do we even want to allow after-the-fact chomps, or do it
> automagically
> > >at read time?
> > "Yes" is rather ambiguous.
>
> To clarify: "Yes", we (I) want to allow after-the-fact chomps. As you
> alluded to yourself there are times when you may want to chomp strings that
> were not read from files, therefore there would be no "read time".
Just because we can do it now doesn't necessarily mean it's the right
thing to do. Arguably anything you use chomp on that didn't come from a
filehandle really ought to be run through a regex.
> > >What about a
> > > chomp($foo, '\r\n');
> > > # or
> > > chomp(<FH>, '\r\n');
> > >syntax.
> >
> > Looks an awful lot like:
> > s/\r\n//;
> > to me...
>
> Yep. It should-- that's all chomp does afterall. The difference is that the
> proposed chomp should be smarter than a regex, since it will assume certain
> defaults, that is: "chomp;" should act like "chomp($_, $/)"; If, however you
> wanted to explicitly say something different you could.
Then that seems both silly and ugly. If 'chomp($_, "\cM\cJ")' is the same
as "s/\cM\cJ$//", why not use the regex form instead? It looks like you're
trying to make chomp a reasonably ugly macro for the substitution
operator. (Which, honestly, is probably what it'll be optimized to)
I don't see the point of adding the form.
Dan
