Re: lvalue substring oddities

in reply to lvalue substring oddities

Personally, I consider the current behaviour as broken as I would consider print sqrt( -10 ); printing 3.16227766016838. Except that I can conceive of the situation whereby the latter result might actually be useful. I could see someone relying upon that broken behaviour and skipping the step of detecting negative values and absing them, if that was the requirement of their application. They shouldn't, but I could see it happening.

However, the current resultant of substr as an lvalue, whilst predictable, is so twisted, and has so many edge cases, I find it inconceivable that anyone has actually found a reasonable use for the current behaviour, much less constructed an application that relies upon it.

I have personally encountered the situation (twice at least) where having the value assigned, returned would have slightly simplified my code.

As such, I would consider this change fixing a broken behaviour, rather than modifying an existing, useful one, and if it served to highlight broken code, or reliance upon undocumented, broken behaviour in existing applications, then so be it. Simplistically, if adding 1 + 1 returned 3 and someone coded their app to rely upon that, we wouldn't think twice about not maintaining backwards compatibility.

To my way of thinking, this fits in the same category.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!
Wanted!

Replies are listed 'Best First'.
Re: lvalue substring oddities by Abigail-II (Bishop) on Nov 12, 2003 at 09:31 UTC
However, the current resultant of substr as an lvalue, whilst predictable, is so twisted, and has so many edge cases, I find it inconceivable that anyone has actually found a reasonable use for the current behaviour, much less constructed an application that relies upon it. Considering that 4-arg substr is a relative new invention (5.004? 5.005?), there must have been a lot of code that uses the lvalue-ness of substr. substr has never surprised me, but then, I've never used the 3-arg form in both rvalue and lvalue context at the same time, nor have I ever used 4-arg substr as an rvalue. I'm not really convinced this issue is worth breaking backwards compatibility for. No doubt there is code right now that depends on this behaviour - and if the current behaviour confuses you, don't use it. Write it in two lines. Abigail	[reply]
Re: Re: lvalue substring oddities by BrowserUk (Patriarch) on Nov 12, 2003 at 14:08 UTC
Sorry, but my contention is that there almost certainly isn't code right now that depends upon this behaviour. The current behaviour is so inherently non-useful, almost unpredictable, that I think it impossible that anyone has found a use for it. Leaving it as it is, just means perpetuating a non-useful, unusable behaviour where a useful behaviour could be provided. I can't believe that you, of all people, are suggesting that the rest of the world eshew a possible, advanced behaviour just because it is not one that you personally have ever thought to try, or because it is easily achieved by the combination of two simpler ones? Of course this is only my opinion and that carries exactly as much weight as anyone cares to give it, but the logic of: Don't make something not useful into something useful because it might break something that is non-useful, but pre-existing. I find faintly ludicrous. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail Hooray! Wanted!	[reply]
Re: lvalue substring oddities by Abigail-II (Bishop) on Nov 12, 2003 at 14:35 UTC
Sorry, but my contention is that there almost certainly isn't code right now that depends upon this behaviour. This is a problem that always plays when there is the suggestion to break backwards compatibility. It's easy to claim there isn't code right now that depends on this behaviour. It's a lot harder to prove that there isn't. Considering the years of Perl programming that have led to millions of lines of code, I'd be surprised if there isn't code that depends on it - whether is was programmed knowingly or not. I can't believe that you, of all people, are suggesting that the rest of the world eshew a possible, advanced behaviour just because it is not one that you personally have ever thought to try, or because it is easily achieved by the combination of two simpler ones? Where did you get this idea from? I just said that substr never surprised me, and stated the reasons why. My reason to not favour this behaviour change have all to do with breaking backwards compatibility - not with personal experience. Now, I'm not against everything that breaks backwards compatibility - but if something breaks backwards compatibility one has to look at the advantages and the disadvantages. The latter means, how much code will break? Probably not much, but how much, we don't know. OTOH, the gain of the proposed change isn't too big either, it could also be archieved by breaking down one statement into two. So, I'm not in favour because I think the possible gain of the change might not outweight the lost (breakage of code). Abigail	[reply]

Replies are listed 'Best First'.

Re: lvalue substring oddities
by Abigail-II (Bishop) on Nov 12, 2003 at 09:31 UTC

However, the current resultant of substr as an lvalue, whilst predictable, is so twisted, and has so many edge cases, I find it inconceivable that anyone has actually found a reasonable use for the current behaviour, much less constructed an application that relies upon it.

Considering that 4-arg substr is a relative new invention (5.004? 5.005?), there must have been a lot of code that uses the lvalue-ness of substr. substr has never surprised me, but then, I've never used the 3-arg form in both rvalue and lvalue context at the same time, nor have I ever used 4-arg substr as an rvalue.

I'm not really convinced this issue is worth breaking backwards compatibility for. No doubt there is code right now that depends on this behaviour - and if the current behaviour confuses you, don't use it. Write it in two lines.

Abigail

[reply]

Re: Re: lvalue substring oddities

by BrowserUk (Patriarch) on Nov 12, 2003 at 14:08 UTC

Sorry, but my contention is that there almost certainly isn't code right now that depends upon this behaviour.

The current behaviour is so inherently non-useful, almost unpredictable, that I think it impossible that anyone has found a use for it. Leaving it as it is, just means perpetuating a non-useful, unusable behaviour where a useful behaviour could be provided.

I can't believe that you, of all people, are suggesting that the rest of the world eshew a possible, advanced behaviour just because it is not one that you personally have ever thought to try, or because it is easily achieved by the combination of two simpler ones?

Of course this is only my opinion and that carries exactly as much weight as anyone cares to give it, but the logic of:

Don't make something not useful into something useful because it might break something that is non-useful, but pre-existing.

I find faintly ludicrous.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!
Wanted!

[reply]

Re: lvalue substring oddities

by Abigail-II (Bishop) on Nov 12, 2003 at 14:35 UTC

Sorry, but my contention is that there almost certainly isn't code right now that depends upon this behaviour.

This is a problem that always plays when there is the suggestion to break backwards compatibility. It's easy to claim there isn't code right now that depends on this behaviour. It's a lot harder to prove that there isn't. Considering the years of Perl programming that have led to millions of lines of code, I'd be surprised if there isn't code that depends on it - whether is was programmed knowingly or not.

I can't believe that you, of all people, are suggesting that the rest of the world eshew a possible, advanced behaviour just because it is not one that you personally have ever thought to try, or because it is easily achieved by the combination of two simpler ones?

My reason to not favour this behaviour change have all to do with breaking backwards compatibility - not with personal experience. Now, I'm not against everything that breaks backwards compatibility - but if something breaks backwards compatibility one has to look at the advantages and the disadvantages. The latter means, how much code will break? Probably not much, but how much, we don't know. OTOH, the gain of the proposed change isn't too big either, it could also be archieved by breaking down one statement into two.

So, I'm not in favour because I think the possible gain of the change might not outweight the lost (breakage of code).

Abigail

[reply]