Re: Request for help in method naming

I'd strongly suggest having tpv ALWAYS return metric measurements. Otherwise people using your objects always need to check which measurement system they're on (apparently by calling $object->_is_metric which looks like a private method they shouldn't be calling). This seems a recipe for disaster. You just know half the time people will just assume it's going to give them metric because that's the default.

If you want to offer imperial units too, define another method tpv_imperial to do that. People who want that, can call it by name and know reliably what they're getting.

Comment on Re: Request for help in method naming Select or Download Code

Replies are listed 'Best First'.
Re^2: Request for help in method naming by stevieb (Canon) on May 18, 2017 at 19:39 UTC
That's the second recommendation for something like this. The first was a dup of `poll()`. This one sounds more logical and sane to me. I can name the inner conversion methods what I want (and have them public), but the names won't matter as much, as the typical end user won't be using them directly. Doing this with `tpv()` makes a great deal more sense, as it provides more flexibility, while allowing `poll()` to do the same thing it does (fetch the data, send it through the parser, and return it as original JSON or original Perl as originally designed). Anonymonk's idea of hacking `poll()` was a good one so I don't want to take away from that, but it does make more sense to implement this in `tpv()` as that's where all of the relevant convertible data is housed), and that's what I think I'm going to do. update:I appreciate those who actually have reached out and viewed the code. It's impressive to me that people do really care :) fwiw, the most recent changes that have been committed can be found in the repo.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Request for help in method naming
by stevieb (Canon) on May 18, 2017 at 19:39 UTC

That's the second recommendation for something like this. The first was a dup of poll().

This one sounds more logical and sane to me. I can name the inner conversion methods what I want (and have them public), but the names won't matter as much, as the typical end user won't be using them directly.

Doing this with tpv() makes a great deal more sense, as it provides more flexibility, while allowing poll() to do the same thing it does (fetch the data, send it through the parser, and return it as original JSON or original Perl as originally designed).

Anonymonk's idea of hacking poll() was a good one so I don't want to take away from that, but it does make more sense to implement this in tpv() as that's where all of the relevant convertible data is housed), and that's what I think I'm going to do.

update:I appreciate those who actually have reached out and viewed the code. It's impressive to me that people do really care :) fwiw, the most recent changes that have been committed can be found in the repo.

[reply]
[d/l]
[select]