-1-

Uri has plusName, plusName, plusQuery, plusSlash except plusExt.

Suggestion: Uri.plusExt(Str ext)

-2-

@Operator div for Uri. Using:

root := `localhost`
category := "sidewalk"
item := `topic`
root/category/topic => `localhost/category/topic`

-3-

There is File.readAllStr but there is no File.writeAllStr.

Suggestion: File.writeAllStr(Str str) writes str in file and closes file InStream.

-4-

// old
"".splitLines => [""]
// new
"".splitLines => [,]

Better if "".splitLines returns empty list instead of list with one empty string. Current behavior confused me.

Lets need to count amount of lines in file:

file.readAllStr.splitLines.size

If file is empty then result 1 although expected 0.

Lets need to wrap up lines in file by tag:

file.readAllStr.splitLines.map{"<tag>$it</tag>"}.join("\n")

If file is empty then result <tag></tag> although expected empty string.

Some nice ideas. Here are my thoughts:

Uri has plusName, plusName, plusQuery, plusSlash except plusExt.

The reason is that you typically need to do some string manipulation. Very rarely would you stick an extension on a URI without stripping the existing ext right?

uri := `foo/file.txt`
uri.parent + `${uri.basename}.newext`

Maybe a replaceExt might make more sense, although even that seems pretty rare.

@Operator div for Uri.

That is interesting idea. Seems a bit like operator abuse, but I'd be interested to hear what others think?

There is File.readAllStr but there is no File.writeAllStr.

I thought about adding something like that to OutStream and File, but decided against it because it such an easy one liner:

file.print(str).close

I guess technically you could make the case that isn't guaranteed to close the stream, but exceptions on output streaming are sort of an odd case. Other thoughts?

Better if "".splitLines returns empty list instead of list with one empty string. Current behavior confused me.

The problem is that "" is a string with one line. Consider these cases:

fansh> "line1".splitLines.join(",") { it.toCode }
"line1"
fansh> "line1\n".splitLines.join(",") { it.toCode }
"line1",""
fansh> "line1\nline2".splitLines.join(",") { it.toCode }
"line1","line2"

The problem is that there is a difference b/w "line1" and "line1\n", the second actually does have a second line even though it is empty.

The "".splitLines case bites me quite a bit - so I would welcome a change here - even if its just an additional parameter (or method) - the workaround today is sorta a pain.

The "".splitLines case bites me quite a bit - so I would welcome a change here - even if its just an additional parameter (or method) - the workaround today is sorta a pain.

I guess we could implicitly remove the last line if it was empty or add another flag for it. Anybody have an issue with that breaking change?

That would break things like a line count just off the top of my head. "line\n" is 2 lines not 1. Removing that implicitly would introduce some subtle bugs, imo. If you added a flag, would it apply only to trailing empty elements? What about empty elements in the middle?

For reference:

cat Split.java && java Split
public class Split {
	public static void main(String[] args) {
		System.out.println("".split("\n").length);
	}
}

1

I think:

"" => 0 lines
"line" => 1 lines
"line\n" => 2 lines
"line\nline" => 2 lines 
"line\nline\n" => 3 lines
"line\nline\nline" => 3 lines  
... 

About -2- Personally I think Fantom could endure more operator abuse (like concat for List that would shortcut to a plus). So +1 to -2-.

As for the -4- maybe another method is in order(splitNonEmpty)?

I think you simply make a special case for "" - otherwise works as it does today.

-1 to making a special case for "".

-1 for operator abuse.

-1 for div. `$root/$category/$item` does the trick.

-1 for div - as ivan said, interpolation works just fine here.

After some thought, I think a skipEmpty param for splitLines would work just fine. In general, if "" was not valid, other empty lines probably aren't either. So keeps the (assuming) common case simple.

"".splitLines        ->  [""]
"".splitLines(true)  ->  [,]

"foo\n".splitLines        ->  ["foo", ""]
"foo\n".splitLines(true)  ->  ["foo"]

original retracted

I just should note that splitLines actually works consistently with split, and I don't think we want to break consistency b/w those:

"".split(',').join(", ") { it.toCode }    =>  ""
"x".split(',').join(", ") { it.toCode }   => "x"
"x,".split(',').join(", ") { it.toCode }  => "x", ""