Path#load, shortcut for (YAML/JSON).load(Path#read) #8
Conversation
|
@eregon the feature looks fine now. I'm not huge fan of manipulating file extensions without the dot (and therefore, not a huge fan of Path#ext either). Keeping the dot in such situations announces very clearly that one talks about a file extension and not the underlying file format or something (think about 'doc' vs. '.dot', 'yaml' vs '.yaml', or a google search about a file extension you don't know). Whatever the choice in epath, we should stick to one convention and announce it clearly. |
|
For this particular case, we could accept both formats, as sub_ext does. I agree the leading dot is useful when speaking or describing it, but I'm less sure in a programming language how that can ever be useful except for avoiding confusion. Practically I found myself adding the dot via I also think of the extension as a "second level split". And here is the "second level split": It just seems logical to me in respect of the first. WxWidget for example has an interesting function SplitPath, which splits in volume, dirname, name and ext, without dot. (In all generality, we could think of a path as a part of an URI, as this diagram shows. Clearly, the '://' is neither part of the scheme nor the rest.) I searched around the web, and there seems to be no single standard, although the leading dot seems more used. Sometimes the term 'type' is used to denote an extension without dot. We could use that but I feels it is less natural and the usage seems very small. Ruby usually tries to present an uniform interface to users, so for example paths always use a '/' separator, and so it seems to make sense extensions are always presented as separated by '.'. These are my arguments, what are yours? |
|
I must confess that your vision makes perfect sense. Anyway, I don't really have any strong argument in favor of one of those conventions. The only stuff is that I often think "with the dot" and I would expect a Path library to let me do it, in the name of POLS. I strongly guess that I'm not the only one, as File#extname suggests. In any case, I really think that announcing the specification very clearly is the best and only way to manage such cases... Do what you think is the best, really! |
I'm very happy you understood my idea.
Yes, even if it was not for compatibility I would provide a way to get the extension with the dot.
Will do that in the README ASAP. |
Path#load and Path.register_loader Conflicts: spec/epath_spec.rb
|
Merged, thanks a lot! I'll leave it open until I'll document the extension specification. |
|
@blambeau I finally wrote about it, what do you think ? |
|
Very clear IMHO! Good job! |
|
Thanks! |
|
@blambeau Turns out I changed my mind and went to #ext being #extname for Path 2.0, with the dot (there is #pure_ext for extension without the dot). |
|
Ok. I'm not sure to understand how exactly such change will impact existing code but anyway. Btw, would you mind start documenting backward incompatible changes in the changelog? I use Path almost everywhere now and would like to make sure that my libs will migrate as smoothly as possible. Thanks! |
|
Yeah of course I will document it clearly, 2.0 is not released yet, just on master. |
Sorry for the confusion but github didn't follow the branch renaming on my fork...
Anyway, no new commit here for now. See #4