Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'm not sure if the first example is fair. Simple method overloading in Java or C++ is generally used for functions that can take different parameter types, which isn't an issue in Perl, or to have functions with optional parameters which again isn't much of a problem in Perl:

    sub someMethod {
        my $self = shift;
        my $foo  = shift || 1;
        ...
    }

    I think that method overloading is more tied to the fact the a language is statically typed and not necessarily something

    • Well, you say it's not much of a problem, but look at the snippet you posted:

      sub someMethod {
          my $self = shift;
          my $foo  = shift || 1;
          ...
      }

      Can $foo be 0? Your code says 'no', but that might or might not be what you meant. Also, by the time you've finished the $foo line, you no longer can easily tell whether or not you even passed an argument for $foo.

      In my original example, the code might do strange things if too many arguments are passed, or if they're n

      • When I said that it wasn't a problem I meant that it wasn't a problem to implement. Which isn't to say that there won't be problems in the implementation.

        Some of these problems could be solved efficaciously with method overloading. Nevertheless, I still think that method overloading is mainly a necessity of static typing. Which for me is a more useful language feature and one that we have learned from since it will be included in Perl 6.

        John.
        --

  • Off the top of my head...

    Pop-11: Assignment was done with the right-arrow operator.

    ;;; perl's $x = 10 would be written as
    10 -> x;

    Which has the advantage (as far as I'm concerned anyway :-) of reading naturally ("10 goes into x") and allowing us to use "=" to indicate equality as god intended, removing all of those "if x=10" type errors.

    Pop-11: The "updaterof" idiom (see this example [perlmonks.org]) that gave a nice way of separating access/mutate methods.

    Pop-11: direct access to the parser/compiler for the l

  • I still don't understand why the Smalltalk way of ifTrue: and ifFalse: is superior to if/else. Can you please explain?

    Other than that, one thing I can think of is the Scheme/SICP [mit.edu] way of handling linked lists using car, cdr, cons, and recursion. This makes the code much more robust and much less error prone than using pointer games, as is often the case in C. Funnily enough, when I wrote similar code in Common Lisp, the people on #lisp on Freenode told me that I shouldn't use recursive helper functions

  • I recall that in "thinking in forth" there was a whole chapter about this :) Anyway I'd say: predicate dispatch, which encompasses both pattern matching, overloading/mmd, and eliminates the need for if statements and switch/case. The nice thing about predicate dispatch is that even your basic control structures remains open for change, it's the same shift from a huge switch/case and OO design. Already in perl6 afaict :).