Implement and deploy the path utility class #191
Conversation
| Path &push(const T &path) { | ||
| return push(Path(path)); | ||
| } | ||
| Path &pop(); |
There was a problem hiding this comment.
If push() and pop() are too cryptic, is there a better candidate pair? enter()/exit()?
There was a problem hiding this comment.
enter() and exit() are also very weird for me. The problem for pop() is we usually get the popped value instead of the remaining part from calling it.
How about append()/attach() and remove()/detach()/drop()?
There was a problem hiding this comment.
The advantage of enter() is that it sounds less misleading when the argument is an absolute path or a relative path prefixed with a different root name. I have mixed feeling on append(). It's better than others considering C++17 uses that name, and also worse due to the lack of an obvious antonym. Perhaps drop() or strip() is acceptable if we have to choose append(), but be aware it shares the same pitfall as pop(): the result for "../.." should be "../../.." instead of "..".
The biggest motivation of the path utility class is to serve the migration to Abseil, whereas a completely different proposal is to revert #124, as if we invented a "better" option parser than Abseil. Then nothing in 3rd-party needs further elimination, and at the same time nothing is blocked by this PR, as long as I can leave the legacy code as TBD until the arrival of C++17.
There was a problem hiding this comment.
I just recalled why enter() and exit() were turned down at the very beginning of this work: while it sounds good for "enter/exit DIRECTORY", it's improper to say "enter/exit FILE". So there's still no plausible names :(
"There are only two hard things in computer science: cache invalidation and naming things."
2 participants
No description provided.