View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000180 | LDMud 3.5 | Efuns | public | 2004-11-26 22:21 | 2009-10-07 07:56 |
| Reporter | Assigned To | zesstra | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
| Summary | 0000180: Behaviour of explode("", "whatever") | ||||
| Description | Short: Behaviour of explode() From: Matthew Julius <julius.2@wright.edu> Date: Fri, 08 Jan 1999 16:29:08 -0500 Type: Feature State: Unclassified explode("", "\n") returns ({ "" }) Snort. This should not be so. alfebtcd wrote: > no? why not? what should it be? all i want to be sure of is that it > doesn't change every day and that x == implode(explode(x,y)) works for > all legal x and y. Erm. I must not have checked this correctly. I thought I tested it and it did not work correctly. However, after checking again I see that it does not cause any problems. The change was from the MudOS changelog so I can only assume I was thinking of something else when I mentioned it. Ahh yes, now I remember. I was confused in that explode("", "") == ({ }) This is different than, for example, explode("", "anything") == ({ "" }) explode("", whatever) should perhaps always return ({ "" }) | ||||
| Tags | No tags attached. | ||||
|
|
> explode("", whatever) should perhaps always return ({ "" }) Returning ({""}) seems to make sense to me. At least more than to return ({}) in explode("","") and ({""}) in explode("","whatever"). But how much breaks, when we just return ({""}), when the exploded string is ""? I guess not too much, because in most cases it anyways returns ({""})... |
|
|
This is fun. There are infinitely many solutions for explode(whatever, "") that satisfy implode(explode(whatever, ""), ""). For whatever = "", there are three noteworthy ones: ({}), ({""}), and ({"", ""}). Each one has its logic: explode(whatever, whatever) returns always ({ "", "" }). explode("", whatever) returns always ({ "" }). sizeof(explode(whatever, "")) is always sizeof(whatever). Perhaps make that configurable. :-D |
|
|
Oh, I forgot: explode(n*whatever, whatever) returns always (n+1)*({""}). One of our wizards said, that when there are more than one solution, explode() should return the shortest one. And I agree. We should leave it as it is now. PS: On the other hand, that's the only occasion where explode() returns an empty array. Normally you can rely on the fact that explode(x,y)[0] exists. :-) |
|
|
That reasoning is not bad... I slightly favor the change to ({""}) because of your PS. I actually remember, that I was quite a long time the opinion, that explode will never return an empty array, because it returned a non-empty one on explode("","bla"). Therefore my code probably misses necessary checks an some points... ;-) |
|
|
Even after long years of programming LPC, I'm surprised that explode() returns an empty array in one case. It was also my opinion, that explode()[0] exists. I'm not aware of any code in the mudlib (area lib) that checks for an empty result array of explode(). I also suggest to let explode("", whatever) always return ({""}). As a next consequent step, implode(array, whatever) could return an error if the given array is empty. |
|
|
I agree with Coogan and would change that for 3.5 and maybe for 3.3, if you think, the change in behaviour is not too big. |
|
|
It is rather unpredictable how much code this will break. So I'd say we do this in 3.5 only. |
|
|
Right. Moved to 3.5. |
|
|
I applied a patch to return ({""}) for empty strings in r2763. Additionally added some tests for explode checking the new behaviour and the example from the manpage. ;-) |
|
|
Implemented Coogans suggestion as r2764. Added some tests for implode as well. I hope, that it will not cause too many errors. Otherwise we may have to reconsider. |
|
|
There was a discussion about the issue of implode() raising an error if given an empty array on -d-code. Bardioc requested to keep the old behaviour. I thought it to be a bit more consistent to the new explode behaviour, but overall I am quite indifferent. |
|
|
This will break a lot of code, since explode() is not the only source of input to implode()... and up to now implode(({}),... works just fine. |
|
|
OK, due to popular demand I removed the check for the empty array in implode() in r2766 (but kept the other changes like tests). ;-) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 22:21 |
|
New Issue | |
| 2009-09-28 13:02 | zesstra | Note Added: 0001325 | |
| 2009-09-29 14:05 | Gnomi | Note Added: 0001344 | |
| 2009-09-29 14:22 | Gnomi | Note Added: 0001346 | |
| 2009-09-30 16:03 | zesstra | Note Added: 0001358 | |
| 2009-10-01 04:13 | Coogan | Note Added: 0001387 | |
| 2009-10-05 18:29 | zesstra | Note Added: 0001476 | |
| 2009-10-05 18:29 | zesstra | Assigned To | => zesstra |
| 2009-10-05 18:29 | zesstra | Status | new => assigned |
| 2009-10-06 02:35 | Gnomi | Note Added: 0001483 | |
| 2009-10-06 03:41 | zesstra | Project | LDMud => LDMud 3.5 |
| 2009-10-06 03:42 | zesstra | Note Added: 0001486 | |
| 2009-10-06 03:42 | zesstra | Product Version | 3.2.8 and before => |
| 2009-10-06 03:42 | zesstra | Target Version | => 3.5.0 |
| 2009-10-06 17:31 | zesstra | Note Added: 0001501 | |
| 2009-10-06 18:11 | zesstra | Note Added: 0001502 | |
| 2009-10-06 18:11 | zesstra | Status | assigned => resolved |
| 2009-10-06 18:11 | zesstra | Fixed in Version | => 3.5.0 |
| 2009-10-06 18:11 | zesstra | Resolution | open => fixed |
| 2009-10-07 07:25 | zesstra | Note Added: 0001510 | |
| 2009-10-07 07:25 | zesstra | Status | resolved => assigned |
| 2009-10-07 07:25 | zesstra | Resolution | fixed => reopened |
| 2009-10-07 07:36 | Sorcerer | Note Added: 0001511 | |
| 2009-10-07 07:56 | zesstra | Note Added: 0001512 | |
| 2009-10-07 07:56 | zesstra | Status | assigned => resolved |
| 2009-10-07 07:56 | zesstra | Resolution | reopened => fixed |
