in reply to $bad_names eq $bad_design

if you can't figure out a good function name, look for a design problem.

That seems like sound advice. (Heck, any reason to look for a design problem is a good one.) Even though it makes a good rule of thumb, like most advice, it could be hazardous if followed in every instance. Sometimes an awkward function is the right one. Code is not natural language afterall. Consider that, if you allow your spoken language to have too great an influence on how you code, you may be artificially limiting your design choices right from the start.

I think it is best when code approximates a written description. It needn't actually read like one. Frankly, your use of "_are_the_" in a subroutine name makes me cringe. Why? Because words of that nature could crop up in lots of subroutine names and when that happens your eye has to work harder to differentiate them.

Instead of tokens_are_the_same(), I would be inclined to use something like tokens_same(). I might call it tokens_equal() or tokens_equivalent() depending on what it actually did. (I think 'same' indicates that two references refer to the same memory, 'equal' indicates that the values are the same, and 'equivalent' indicates that two values have the same type. For instance, two STRING tokens might be equivalent but not necessarily equal or the same.) In general, I think good subroutine names are as short and dense with meaning as possible without being cryptic.

"My two cents aren't worth a dime.";

Replies are listed 'Best First'.
Re: Re: $bad_names eq $bad_design
by BrowserUk (Patriarch) on Dec 21, 2002 at 11:30 UTC

    Here, here!

    Whilst I want my code to be self-documenting, extraneous "little" words in sub and variable names do "little" to enhance this IMO too.

    That's probably the strongest argument for properly executed overloading.

    if ( $current_token == $token ) {...} where $current_token is an object of a class Token that overloads the == operator and does the right thing would be so much more intuative I think.

    To my way of thinking, overloading is more useful than inheritance for giving clarity, especially when the latter is taken too far. Java's propensity to use inheritance rather than attributes combined with the need for (which this practice in part generates) long, unweildy class and method names leading to stuff like

    Reader in = BufferedReader( UnbufferedReader( Stream( filename ).getStreamHandle()) );

    drives me nuts:^) (That's from memory, inaccurate and an exaggeration, but it makes my point).

    It's also part of the reasoning behind my desire for lvalue subs (with appropriate mechanisms for preinspection and rejection of assignment attempts), for use as assessor/mutator methods. Having to write

    my $point = new Point(); $point->set_X( 3 ); $point->set_Y( 4 ); .... my $start_point = new Point; $start_point = $point.copy(); $point->set_X( $point->get_X() + 1 ) while $image->get_color_at($point) == RED; my $end_point = new Point(); $end_point = $point->copy(); $image->draw_line_from_to( $start_point, $end_point, BLACK );

    When it could be

    my $point = new Point(3, 4); ... my $start_point = $point; $point->X++ while $image->color_at($point) == RED; # or even $point-> +X = point->X + 1 my $end_point = $point; $image->line( $start_point, $end_point, BLACK );

    seems unnecessarially unweildy to me.

    Examine what is said, not who speaks.

      I'm not sure I'd go with the operator overloading here. It does mean you have to keep a firm grasp on all the interfaces and remember what a variable is supposed to contain. It also makes spotting mistakes harder - if I have the wrong object in $current_token, $current_token->equals($token) may well have Perl complaining it can't find that method, while $current_token == $token will (more or less) quietly do the wrong thing.

      I like overloading, but I believe it is very, very dangerous if used too readily. It's great when you're creating a class that shares characteristics with the basic data types, like writing a Math::Complex or something, where $a * $b ends up meaning exactly what I expect. Also, overloading stringification is very handy. I would be really hesitant to use it to represent more arbitrary semantics.

      As for your example, I'd probably want something like this:

      my $point = new Point(42, 42); my $start_point = $point->copy; $point->add_x(1) while $image->element_at($point)->color == RED; my $end_point = $point->copy; $image->draw_line($start_point, $end_point, BLACK);

      Makeshifts last the longest.

        First, it should really be eq rather than ==, but I'm not yet sure which operators perls overloading can handle, not having made any use of it, but the example was intended as pseudo code rather than anything anyone would implement.

        That aside, I do agree that overloading needs to be used with care, but I wouldn't consider equality testing abitrary semantics. I can however see your point in this regard given a non-implemented method, though it would rapidly show up in testing. The alternative would be to require that objects implement (even if only dummy) methods for the common operators, but that smacks of Java exceptions and is completely against the spirit of Perl.

        You could view this type of failure (or lack of failure:) under the heading caveat implementor as with some much of standard perl stuff.

        I'm not really sure to which extreme I would tend. I need more time using perl and to read more opinions before I could make that choice.

        Examine what is said, not who speaks.