13 Mar, 2010, Deimos wrote in the 1st comment:
Votes: 0
# This actually gives me ["abc"], instead of ["abc",""] like I would expect.
# Any ideas on a good alternative to get what I want?
"abc\n".split("\n")


Edit: To clarify, what I'm looking for is functionality equivalent to PHP's explode(). Basically, it does the same thing as Ruby's split(), except it treats the special cases where delimiters are at the beginning and end like I want it to:

//  This gives me ["abc",""] like I would expect:
explode ( "abc\n", "" );
13 Mar, 2010, Runter wrote in the 2nd comment:
Votes: 0
Oh, hold on.

Quote
irb(main):004:0> "abc\n".split("\n", -1)
=> ["abc", ""]
13 Mar, 2010, David Haley wrote in the 3rd comment:
Votes: 0
This appears to be a 'feature' of Ruby string splitting, which, incidentally, is a 'feature' shared by Perl 5 but not Perl 6. Python also does not behave like this. For comparison's sake, the language-that-shall-not-be-named doesn't have a standard split function; you extract things by matching. (This can be used to split if you negate the pattern.) The Ruby documentation is rather unclear on this point IMO, but basically what's happening is that trailing empty matches are stripped. Since the one (and only) match (the documentation calls it a "field" for some reason, which I find misleading) is empty, and is also trailing, it gets stripped. It would appear that you might have no choice but to test for the empty string/array explicitly.
13 Mar, 2010, Runter wrote in the 4th comment:
Votes: 0
rdoc said:
If the limit parameter is omitted, trailing null fields are suppressed. If limit is a positive number, at most that number of fields will be returned (if limit is 1, the entire string is returned as the only entry in an array). If negative, there is no limit to the number of fields returned, and trailing null fields are not suppressed.


I found it pretty easy to understand. :p
13 Mar, 2010, David Haley wrote in the 5th comment:
Votes: 0
What the doc says is that trailing null fields – if you realize that "fields" means "matches" – are omitted when the limit parameter is omitted. The sentence construction makes it rather clear that that operation only applies when the limit is omitted, although that is not what, in fact, happens. While it is true that "trailing" implies "the only one" when there is but one, it could be clearer on that point too. Oh well. I also find it somewhat interesting that perl 6 chose to "correct" this from perl 5, but Ruby does what the older perl does.
13 Mar, 2010, Runter wrote in the 6th comment:
Votes: 0
David Haley said:
What the doc says is that trailing null fields – if you realize that "fields" means "matches" – are omitted when the limit parameter is omitted. The sentence construction makes it rather clear that that operation only applies when the limit is omitted, although that is not what, in fact, happens. While it is true that "trailing" implies "the only one" when there is but one, it could be clearer on that point too. Oh well. I also find it somewhat interesting that perl 6 chose to "correct" this from perl 5, but Ruby does what the older perl does.


I dunno. It took me about 5 seconds to read the documentation and about another 5 seconds to type it in IRB to see if it does what I thought it meant. I like the way Ruby does it. Considering, you know, Ruby does a lot of things differently than perl, wasn't made by the people who made perl, and is used by far more people (i.e., people who never used perl) than perl ever was. So I don't understand why what perl did is even important on the subject since there's no agreement here that it was right or wrong.

edit: And just to be clear it's this line in that passage that made it obvious imo.
"If limit is a positive number, at most that number of fields will be returned (if limit is 1, the entire string is returned as the only entry in an array)."

That clearly says that fields are the things being returned, and if limit is 1 it even says "is returned as the only entry in the array"

With these context clues I don't think it's difficult. And if they had used the word matches there would be ambiguity since it has a slightly different functionality when using a regular expression. This is where they chose to use the word matches
"If pattern is a Regexp, str is divided where the pattern matches."
13 Mar, 2010, Deimos wrote in the 7th comment:
Votes: 0
Basically, there's 3 special cases I need covered:

1) "abc\n" = ["abc",""]
2) "\nabc" = ["","abc"]
3) "" = [""]

Runter's solution solves the first two (which is two better than I could figure out :tongue:), but not the last one, as "".split("\n",-1) returns [] instead of [""], unfortunately.

I found this in the docs:
rdoc said:
if limit is 1, the entire string is returned as the only entry in an array

But this appears to be incorrect for my example:
irb(main):008:0> "".split("\n",1)
=> []
13 Mar, 2010, Runter wrote in the 8th comment:
Votes: 0
I could argue that "" shouldn't return anything if it's split by "\n" into anything. Eh, but I wrote some code to solve this if you want it anyways.

class String
alias old_split split

def split arg, limit=nil
val = case limit
when nil then old_split(arg)
else old_split(arg, limit)
end

if val.empty?
val = [""]
end

return val
end
end



p "".split("")
13 Mar, 2010, David Haley wrote in the 9th comment:
Votes: 0
Quote
and if limit is 1 it even says "is returned as the only entry in the array"

Hmm, yeah, except that's not what actually happens for the empty string. :wink:

Quote
So I don't understand why what perl did is even important on the subject since there's no agreement here that it was right or wrong.

Well, there's consensus, to start with. But what I found interesting was precisely that perl chose to change their behavior away from this. Presumably, they thought it was flawed.

Quote
I could argue that "" shouldn't return anything if it's split by "".

If I'm not mistaken, nobody asked for this. That said, "".split("") should give you the same result as "".split("\n") for consistency's sake.

I think it's funky to trim trailing empty fields. If I do "abc\n\n\n\n\n".split("\n") I really expect to get abc followed by several empty strings. If I wanted to chomp the string, then I'd – you know – chomp the string!
But, eh. Let's stop now before I incur the ire and wrath of Mr. T. (But hey– I'm talking Ruby.)
13 Mar, 2010, Deimos wrote in the 10th comment:
Votes: 0
Yeah, it could be argued either way, I guess. I'm only needing this in one spot, so I'll probably forego extending String and just explicitly check for an empty string there (less code).

I appreciate the help, though!
13 Mar, 2010, Runter wrote in the 11th comment:
Votes: 0
Deimos said:
Yeah, it could be argued either way, I guess. I'm only needing this in one spot, so I'll probably forego extending String and just explicitly check for an empty string there (less code).

I appreciate the help, though!



Unless you're calling it 100 times a second I don't see why it would matter honestly to just extend it. I mean, isn't that what we've been talking about? That you think the functionality should work that way even when you don't need it? :p
13 Mar, 2010, Deimos wrote in the 12th comment:
Votes: 0
Runter said:
Unless you're calling it 100 times a second I don't see why it would matter honestly to just extend it. I mean, isn't that what we've been talking about? That you think the functionality should work that way even when you don't need it? :p

Well, no, not necessarily. I don't have any problem with the way String#split works. I'm just in constant PHP-mode because that's about all I do at work and it's hard for my brain to switch gears! Especially to something as unfamiliar to me as Ruby. I'm actually loving the language so far, though.
13 Mar, 2010, Runter wrote in the 13th comment:
Votes: 0
Deimos said:
Runter said:
Unless you're calling it 100 times a second I don't see why it would matter honestly to just extend it. I mean, isn't that what we've been talking about? That you think the functionality should work that way even when you don't need it? :p

Well, no, not necessarily. I don't have any problem with the way String#split works. I'm just in constant PHP-mode because that's about all I do at work and it's hard for my brain to switch gears! Especially to something as unfamiliar to me as Ruby. I'm actually loving the language so far, though.


It's a fun language and it won't take you long to get familiar with it. I think as far as the mud community goes it could be something that really catches on if there were more MUD related resources available for it. Such as fully developed, simple MUD servers more diku styled.

I may try to write a clone of rom in Ruby when I don't have so much on my plate. It's something I've talked about in the past.

I'm actually lucky enough to be able to use Ruby at work. :)
0.0/13