stevieb has asked for the wisdom of the Perl Monks concerning the following question:

Theoretical question bound for opinionated answers alert...

So in my GPS distribution, I've decided that I want to make certain items toggle-able. First, some informational aspects are measured in metres-per-second by default. These include altitude, current speed and current lateral movement. I am trying to design a mechanism whereby someone presses a button (calls a method) it toggles between metric (metres) and imperial (feet). The other toggle I am creating is turning a signed decimal (latitude and longitude) into it's (for lack of better terms that I don't know yet) "English" counterpart. An example of this would be converting -114.1234567 into 114.1234567W (note the 'W' at the end).

At first, I was only converting these internally, and only if a param was sent into the object instantiation method (new()). I have decided I want to make this functionality available at runtime.

Now, at first, when the code was only being init in new, it was simple. I had a _metric() and _signed() methods. They make sense internally to me and to the software. The program run will either be metric or not, and signed or not.

To expose these two options as methods, I can't think of a good name for them that encompasses what they do. For the 'metric' conversion, I plan on declaring like this: sub_name($decimal);. I could just work on the innards of the object where the relevant pieces are stored, but it would be handy for testing and other instances to be able to throw in any numbers, not just what we've collected. The declaration for the conversion of signed to "English" will be something like: sub_name($lat, $lon);.

Internally, there's already a check to see whether something is metric or signed or not, so the toggle piece already works. It's the names I'm looking for. I don't want something crude like convert_lat_lon(). The name metric() *could* stand, but when going from metric to imperial, I kind of just don't like it.

Looking for any and all suggestions for the naming conventions of these two simple methods :)

Because it's Perlmonks, here's some untested code that I started to write before I came here for some insight...

sub metric {
    my ($self, $stat, $metric) = @_;

    if ((! defined $metric || ! $metric) && ! $self->_is_metric) {
        $stat = $stat * 3.28084;
        $self->{tpv}{$_} = substr($stat, 0, index($stat, '.') +1 +3);
        $self->_is_metric(1);
    }
}

[download]

At the time, I was considering using the metric name and throwing in an extra param, but I really don't like that.

Replies are listed 'Best First'.
Re: Request for help in method naming
by tobyink (Canon) on May 18, 2017 at 19:16 UTC

    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.

[reply]
[d/l]
[select]

      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]
Re: Request for help in method naming
by jdporter (Paladin) on May 18, 2017 at 20:09 UTC

    Tangent: Please don't call it "imperial" unless you're 110% sure that's what you mean. The system in use the U.S. is not called the "imperial" system.

[reply]

      Thanks, jdporter.

      I do understand the differences, but for the better part of understanding in this context I used the "imperial" term in hopes for a broader understanding.

      I do appreciate you pointing this out though.

[reply]
Re: Request for help in method naming
by Anonymous Monk on May 18, 2017 at 18:26 UTC
    to_meters() and to_feet()

    to_signed() and to_compass()

    Don't overthink things. :)

[reply]

      I do like that, and had considered something like that. I was kind of hoping to have one method per, but in the end, I'm thinking this still makes the most sense. It is clear and concise, and there's no ambiguity or confusion.

      Thanks.

[reply]
Re: Request for help in method naming
by Anonymous Monk on May 18, 2017 at 18:36 UTC

    Uh... Maybe have two different poll() methods, one that returns a metric set, other for imperial? You can return an object with the measurements at a specific point in time, while the gps object has the device config and parameters.

[reply]
[d/l]

      That's a decent approach, but I'm thinking more along the lines of something so that the values themselves can be sent in, so the methods can operate outside of the core data storage.

      This way, parts of this module can be used without having to actually generate or used stored organized data to do some translations.

      This would definitely work though, and I hadn't thought about such an approach. It would be trivial to have poll() accept another parameter, and on each call, even an interrupt via a button could set this param (or unset it).

      I appreciate the feedback. I will keep it in mind and play around for sure.

[reply]
[d/l]

Back to Seekers of Perl Wisdom