View Issue Details

IDProjectCategoryView StatusLast Update
0000180LDMud 3.5Efunspublic2009-10-07 05:56
ReporterlarsAssigned Tozesstra  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Target Version3.5.0Fixed in Version3.5.0 
Summary0000180: Behaviour of explode("", "whatever")
DescriptionShort: 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 ({ "" })
TagsNo tags attached.

Activities

zesstra

2009-09-28 11:02

administrator   ~0001325

> 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 ({""})...

Gnomi

2009-09-29 12:05

manager   ~0001344

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

Gnomi

2009-09-29 12:22

manager   ~0001346

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. :-)

zesstra

2009-09-30 14:03

administrator   ~0001358

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... ;-)

Coogan

2009-10-01 02:13

reporter   ~0001387

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.

zesstra

2009-10-05 16:29

administrator   ~0001476

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.

Gnomi

2009-10-06 00:35

manager   ~0001483

It is rather unpredictable how much code this will break. So I'd say we do this in 3.5 only.

zesstra

2009-10-06 01:42

administrator   ~0001486

Right. Moved to 3.5.

zesstra

2009-10-06 15:31

administrator   ~0001501

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. ;-)

zesstra

2009-10-06 16:11

administrator   ~0001502

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.

zesstra

2009-10-07 05:25

administrator   ~0001510

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.

Sorcerer

2009-10-07 05:36

updater   ~0001511

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.

zesstra

2009-10-07 05:56

administrator   ~0001512

OK, due to popular demand I removed the check for the empty array in implode() in r2766 (but kept the other changes like tests). ;-)

Issue History

Date Modified Username Field Change
2004-11-26 21:21 lars New Issue
2009-09-28 11:02 zesstra Note Added: 0001325
2009-09-29 12:05 Gnomi Note Added: 0001344
2009-09-29 12:22 Gnomi Note Added: 0001346
2009-09-30 14:03 zesstra Note Added: 0001358
2009-10-01 02:13 Coogan Note Added: 0001387
2009-10-05 16:29 zesstra Note Added: 0001476
2009-10-05 16:29 zesstra Assigned To => zesstra
2009-10-05 16:29 zesstra Status new => assigned
2009-10-06 00:35 Gnomi Note Added: 0001483
2009-10-06 01:41 zesstra Project LDMud => LDMud 3.5
2009-10-06 01:42 zesstra Note Added: 0001486
2009-10-06 01:42 zesstra Product Version 3.2.8 and before =>
2009-10-06 01:42 zesstra Target Version => 3.5.0
2009-10-06 15:31 zesstra Note Added: 0001501
2009-10-06 16:11 zesstra Note Added: 0001502
2009-10-06 16:11 zesstra Status assigned => resolved
2009-10-06 16:11 zesstra Fixed in Version => 3.5.0
2009-10-06 16:11 zesstra Resolution open => fixed
2009-10-07 05:25 zesstra Note Added: 0001510
2009-10-07 05:25 zesstra Status resolved => assigned
2009-10-07 05:25 zesstra Resolution fixed => reopened
2009-10-07 05:36 Sorcerer Note Added: 0001511
2009-10-07 05:56 zesstra Note Added: 0001512
2009-10-07 05:56 zesstra Status assigned => resolved
2009-10-07 05:56 zesstra Resolution reopened => fixed