in reply to Re^3: Perl Vs Ruby
in thread Perl Vs Ruby

I'm no Ruby expert, could you please explain or at least "link" to what you mean with : )

> Perl has less of that, but it does offer a more consistent way of creating and passing functions.

Replies are listed 'Best First'.
Re^5: Perl Vs Ruby
by Joost (Canon) on Nov 26, 2008 at 21:55 UTC
    Perl has a single operator to create functions: sub, which is used to create named functions and (anonymous) function refs. It also has some syntactic sugar in that you can create a prototype that takes as it's first argument a function ref, by calling
    some_function_with_ref_prototype { |params| do_something_with params } + "bla", $foo.
    Note that the sugar looks great when you want to re-implement something matching grep or map as defined in the perl core but not for more interesting stuff like if or when constructs. It also immediately breaks down if you want to use OO, since prototypes aren't supported on methods.

    In ruby every function is a method, and functions can create some special sugar that allows you to use a code block as the last element. Once you've seen it it's apparent that this variant is much more useful, especially since the ruby core uses the same construct for a lot of stuff that's "special" in perl, like iterators:

    some_array.each { |element| # do something with element }
    For more examples, see the Enumerable module, which is used by pretty much every collection-type object in Ruby - meaning you can use each/map/grep/etc on every object that implements only a few primitive methods and includes that module (or doesn't include the module but implements the map/grep/etc methods itself).

    The "problem" is, that ruby makes it slightly harder to pass named functions as blocks/procs, because blocks there have special scoping/lookup rules (since they're not methods).

    See Proc vs Method for example (I don't think blocks are first-class objects).