define /(string,string) = joinpath for strings?

[stevengj]

An interesting suggestion made by @Carreau in JuliaLang/IJulia.jl#210 was to define / for strings as joinpath.

This would make file-handling code a lot cleaner looking, e.g. compare joinpath("METADATA", pkg, "versions") to "METADATA"/pkg/"versions". joinpath is probably one of the most common uses of string concatenation (I count almost 60 calls in Base).

Con: we've usually avoided in Julia this kind of "cute" overloading that completely changes the meaning of an operator, and this would make / for strings completely unrelated to an inverse * (concatenation) for strings. Pro: working with files is one of the most central tasks in any programming language, and / is way easier and more readable than joinpath. It seems unlikely that we will provide an approximate division operation for strings, and one can always use ÷ for exact "division" (suffix stripping).

Just wanted to throw the idea out there.

[Carreau]

Beyond overloading for Strings, I would also (re)consider a specific type.

Agreed that / for all strings would be weird. If path where a specific type you could have / on string return a path.

I found an old discussion about specific type for path in 2012 (sorry phone so no link), Jeff was against.

One of the advantage I suppose would be that you can insure that a path would alway be consistent (no double / in the middle) and/or use \ for separator in windows, directory ends with trailing /... Etc

I think it would also simplify the vocabulary so that you could call split and join or even abs without post fixing everything with "path"

I believe a second similar subtype for URI would be interesting (differ from path by the fact that there would be no /->\ on windows.

Python 3.4 iirc introduce a notion of path class exactly for these issues that are painful.

And in IPython the not having path/uri type is a huge pain, especially since we map uri to path for the webserver.

Envoyé de mon iPhone

Le 29 déc. 2014 à 19:14, "Steven G. Johnson" [email protected] a écrit :

An interesting suggestion made by @Carreau in JuliaLang/IJulia.jl#210 was to define / for strings as joinpath.

This would make file-handling code a lot cleaner looking, e.g. compare joinpath("METADATA", pkg, "versions") to "METADATA"/pkg/"versions". joinpath is probably one of the most common uses of string concatenation (I count almost 60 calls in Base).

Con: we've usually avoided in Julia this kind of "cute" overloading that completely changes the meaning of an operator, and this would make / for strings completely unrelated to * (concatenation) for strings. Pro: working with files is one of the most central tasks in any programming language, and / is way easier and more readable than joinpath.

—
Reply to this email directly or view it on GitHub.

[Carreau]

One more thing for a path type is that you could define a subtype "ResolvedPath" when you can be insured that /something/../ or ~/path are alway expended and or collapsed. One of the recurrent PR we get on IPython is that we did not called expand user or abspath in some string somewhere and that it breaks on some system with some particular configuration of symlink/non-root install.

IIUC (with my little knowledge of Julia) promotion/conversion would be of great help.

Envoyé de mon iPhone

Le 29 déc. 2014 à 19:14, "Steven G. Johnson" [email protected] a écrit :

An interesting suggestion made by @Carreau in JuliaLang/IJulia.jl#210 was to define / for strings as joinpath.

This would make file-handling code a lot cleaner looking, e.g. compare joinpath("METADATA", pkg, "versions") to "METADATA"/pkg/"versions". joinpath is probably one of the most common uses of string concatenation (I count almost 60 calls in Base).

Con: we've usually avoided in Julia this kind of "cute" overloading that completely changes the meaning of an operator, and this would make / for strings completely unrelated to * (concatenation) for strings. Pro: working with files is one of the most central tasks in any programming language, and / is way easier and more readable than joinpath.

—
Reply to this email directly or view it on GitHub.

[nolta]

Jeff wasn't a fan: #1548

[stevengj]

Ah, closing in favor of #1548.