Re: Re: $bad_names eq $bad_design

[BrowserUk]

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.