he/him 
Strings are terrible representations for file paths. You end up having to do way more work to process them when you're passing it around. Extracting extensions, basenames, crawling up the directory chain etc.
Show this thread
-
I understand the sentiment, but disagree with the proposed solution. A string is the purest representation of a file path. It is human readable, stateless and can be processed using pure functions. Don't abstract it; build better utilities.
I don't really understand. Pure representations aren't the most efficient. I'm talking about code that processes file paths. Unclear how you can create better utilities if the input type is not efficiently cachable.
-
-
It is going to be hard to respond without seeing the subject code. But if I am working _a lot_ with file paths, then your abstraction sounds reasonable. My primary concern would be the fact that it is stateful. Same tradeoffs as with any cache.
-
Though if I were to do it (with cache), then I would likely create a helper object that keeps track of all file paths and provides methods to manipulate those paths. You would pass around this object and file paths (separately).
- 3 more replies
New conversation -
-
-
I'd think about it like URL. Whenever it is serialized it should use the string format. But when you have one in memory a URL instance with `origin`, `protocol`, etc properties makes a lot of sense.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.