From the docs on Uri:

Str name()

Return simple file name which is path.last or null if the path is empty.

Examples:

`/`.name => null

Is there a reason why it can't return "" instead of null? Empty strings are naturally more easy to work with than nulls (even with the newly added operators).

Just wondering if I'm overlooking anything.

Side note, I find it hard to adjust to requiring / at the end of dir Uris, but it makes sense. Just mentioning in passing. I have no full opinion on it.

Is there a reason why it can't return "" instead of null?

I could go either way, there are times I've wanted empty string versus null. Same issue with Uri.ext - what happens if you don't have a dot? I still lean towards null, especially now that we have the null operators:

name := uri.name ?: "Root"

But I could be persuaded to change.

I find it hard to adjust to requiring / at the end of dir Uris, but it makes sense

Yeah it sucks, but then again the whole issue with Uris normalization sucks. Too late to change how the web works though. So this is really the only sane option to ensure that directories normalize correctly. By the way you can use File.make(Uri, false) to implicitly add the trailing slash if the file exists and is a directory. Just be aware that file.uri will then return a different uri than the one you passed to make.

Thanks for the explanation (on both subjects).

For empty paths, I think that "" should be the correct value, if it's not ambiguous. It seems like the right thing to do. I think null should be reserved for special needs where other values are unclear.

I don't particularly like using "" since we already have a very well-established value for "does not exist", that being null. So the current implementation seems correct to me:

Fan Shell v1.0.29 ('?' for help)
fansh> `/foo`.ext
null
fansh> `/foo.bar`.ext
bar
fansh> `/foo.bar`.name
foo.bar
fansh> `/foo`.name
foo
fansh> `/`.name
null

If anyone has a use case that supports otherwise, I'd be open to changes.

I think that we should see how the ? null operators bed down. I suspect that they remove many of the reasons we previously used "" in Java.

I would state that even with ?. and ?: that null should be used only where another value isn't meaningful.

As a great example of null, "hello".index("blah") returns null. That's much better than Java's -1, because -1 doesn't mean the right thing. Try doing math with that:

str := "hello"
i := str.index("blah")
// -1 is extra bizarre here. NullErr works better.
prefix := str.slice[0...i]

However, for the following examples, does "" or null work better?

uri := `/`
echo(uri.name.size) // Do we want NullErr or 0?
echo(uri.name?.size) // Do we want null or 0?
echo("It's \"${uri.name}\".") // Do we want 'It's "null".' or 'It's "".'?
echo(uri.name.lower.contains("hello")) // Do we want NullErr or false?
echo(uri.name?.lower?.contains("hello")) // Null or false?

Frequently empty strings and collections are better than null. Values like -1 and 0 are less often so.

However, I could see arguments that `foo`.ext could be null if `foo.`.ext is "". If the distinction is important, then it's worth making the difference. But null instead of empty shouldn't be chosen just because there's no value.

If something does not exist, its null - that is a universal convention, and makes it consistent to handle (and allows null operators to be used).

Now, if we change the semantics of `/` to say that it does have a valid name, and its an empty string, then your proposal makes sense. I think that is the root question that should be decided. But I would need to see a real example of why it makes sense to do that.

I see where you are coming from Tom - in fact I had the change ready to check in last night, but Andy convinced me to keep it null.

I'm on the fence - so if you convince Andy then I'll make the change.

But I would need to see a real example of why it makes sense to do that.

I think Tom provided a lot of examples which I think are real world. Do you not agree?

I'm looking for a example where you want the exact same code path to run with both a valid name, and a null name. To me I always want my code to branch because `/` and `/foo` are two different things. I'm sure an edge case exists where the empty string would be easier, but I don't think that should be at the expense of the common usage.

When deciding what to do for edge cases like this, it's helpful to formulate the problem recursively. In this case, you can see if the parent of /foo/boo.txt is /foo/, and the name of /foo/boo.txt is boo.txt, then the parent of /foo/, should be /, while the name of /foo/ should be foo/. Similarly, the parent of / should be null, while the name of / should be /.

Currently, the / isn't part of the name for dirs, and I think that's okay. The analysis is still helpful, I think,

Concerning null vs. "", I don't think you need different code paths, which is why I gave my examples. Imagine uri passed in with an unknown value. That's why made it a var rather than a literal on each line. I just wanted to show what would happen for the uncommon case of `/`.

My opinion is why stress out over dealing with the 1% chance of nulls when the normal code path works fine. And I think the example I gave are basically just showing common code paths. I'd rather not have to say (uri.name ?: "") in my code all the time just to avoid different code paths, but I probably would end up doing that if needed.

Going broader, the "1%" thing is the same argument for "not null by default" subject on types generally. As I mentioned before in the "not null" discussions a few weeks back, I like ?. and friends, but I'm afraid of them littering code just because we're afraid of these uncommon nulls lurking about. It's better just to know that null won't be there and to let one code path do all, as much as possible. Again, I agree with the "as much as possible" thing. Sometimes null (or a thrown Err, depending on other issues) is the only sane result (such as in the str.index example).

Even if "not null" doesn't work into the language, I think APIs should avoid null except when other values (or thrown errors) don't make sense.

After sleeping on it - I'm fine with with making `/`.name == "".

I still think ext should return null though when it does not exist.

After sleeping on it - I'm fine with with making /.name == "".

This is most consistent, although I would prefer it if the names of all directories included a slash at the end. Not only is this consistent with the naming convention for files (which leads to lots of elegant recursive code), but you trivially know if something is a directory or a file by looking at the final character.

Thanks for being willing.

I haven't done a full review of the code base. There might be other places where I'd have a similar opinion. I just won't be able to go through things thoroughly, at least not for a while.

Tom - in general for rule for lists is always return an empty list and not null. I haven't followed that rule with Strings as closely, and even this case was a close one.

John - Fan takes extra care to ensure that the pathStr always includes the trailing slash in directories and all the various uri manipulation methods do the right thing. In the cases where it might be ambiguous, the method will take a flag to indicate how to deal with trailing slash. For example see File.make, Uri.plusName, or Uri.plusSlash. But I don't think that name should be extended to include that functionality anymore than accessing individual names in Uri.path should - I think that would make things worse. Names are the things between slashes - and paths are the things which include the slashes - two different things in the Uri API design.

Uri.name returns "" instead of null for next build. I left Uri.ext as is (returns null if no dot in name).