Re: New "cut" operator (was: Pike 8.0 RC1)

On Mon, Nov 17, 2014 at 12:40 AM, Peter Bortas <[email protected]> wrote:
> On Sun, Nov 16, 2014 at 12:50 AM, 郭雪松 <[email protected]> wrote:
>> new operator feature sugest:
>>
>> ("cut left example"<<" ")=="left example"
>> ("cut left example">>"ex")=="cut left "
>
> NAK. It's a very specific and unobvious use of an operator that
> conflict both with both the (unfortunately) adopted C++ iostream
> syntax and the more obvious mathematical "much greater|lesser than".
>
> It looks sort of useful but would do well as a functions to make sure
> the code is readable. Something like this:
>
> string cutback(string text, string divisor)
> {
>     return (text/divisor)[1..]*divisor;
> }
>
> string cutfront(string text, string divisor)
> {
>     return (text/divisor)[0];
> }
>
> With better names if possible.

I'd be inclined to do the first job with sscanf:

sscanf("cut left example","%*s %s",string result) --> result=="left example"

It might be nice to have something like this available, but I agree
that << and >> are bad choices. They're primarily bit shift operators,
and the C++ iostream syntax is already highly abusive. Using operators
in place of function calls seldom works - it's cute, perhaps, but it
often leads to problems. Compare Python's printf-style formatting with
Pike's:

>>> "Hello, %s!" % "world"
'Hello, world!'

> sprintf("Hello, %s!", "world");
(1) Result: "Hello, world!"

Sure, the first one's cleaner... but then it has crazy edge cases with
tuple parameters and trying to cope with more than just one additional
parameter (the operator's binary, the function's variadic), so the
second is much more consistent. In this case, it's not going to run
into that particular problem, but the use of operators for anything
other than their original meaning needs a LOT of justification.
Dividing strings by strings to produce arrays of strings? That's still
division, that makes sense. I like that. Left shifting a string by a
string to push it past some boundary? Hmmmmmmm.... dubious.

ChrisA