NAME
rubyisms - Steal some features from Ruby
SYNOPSIS
package Foo;
use rubyisms;
sub initialize { # We inherit a new from class Class
self->{foo} = "bar"; # And we have a receiver, self
__private_stuff(1,2,3,4);
}
sub __private_stuff {
self->{things} = [ @_ ]; # self is still around
self->another_method;
}
sub my_method {
if ($interesting) { ... }
else { super } # Despatch to superclass
}
sub array_iterator (&@) {
yield() for @_;
}
array_iterator { print $_[0], "\n" } ("Hello", "World");
DESCRIPTION
If you can't beat 'em, join 'em. This module exports some functionality
to make Perl behave more like Ruby.
Additionally, all classes which `use rubyisms' inherit from class
`Class', and take a basic `new' method from there. (which creates a
blessed hash, calls your `initialize' method on it and returns it.)
EXPORT
self
This returns the current receiver of methods. This is defined as
being the first thing which is-a your class which comes first in some
method's `@_'. For instance, in the following case:
sub stuff {
my ($self, @args) = @_;
print self;
}
`$self' and `self' are equivalent here. However, in this case:
sub stuff {
my ($self, @args) = @_;
_more_stuff("Hi!");
}
sub _more_stuff { print self }
The `self' in `_more_stuff' is equivalent to `$self' in its caller:
we walk up the stack until we find something that looks like an
object we're interested in. If we don't find an object we're
interested in, we assume that `self' is the current classs.
Obviously you need to be careful with this! Note that `stuff' expects
to be called in the usual method call manner, with the object as the
first parameter; meanwhile, `_more_stuff' expects the receiver to be
implicit. Be good and consistent and only use implicit recipients in
private methods called from within your class and you'll be all
right.
super
When subclassing a class, you occasionally want to despatch control
to the superclass - at least conditionally and temporarily. The Perl
syntax for calling your superclass is ugly and unwieldy:
$self->SUPER::method(@_);
Especially when compared with its Ruby equivalent:
super;
This module provides that equivalent.
It has been pointed out that using `super' doesn't let you pass
alternate arguments to your superclass's method. If you want to pass
different arguments, well, don't use `super' then. D'oh.
yield
`yield' provides iterators in Ruby, and now it does so in Perl too.
However, in Ruby, methods all take an optional block after their
usual arguments. In Perl, we have to fake it. The `&' subroutine
prototype character allows us to take a block and have it passs in as
a coderef, but only if it's the first parameter to a subroutine. For
instance, here's how you'd normally code an iterator:
sub each_array (&@) {
my ($coderef, @args) = @_;
for (@args) {
$coderef->($_);
}
}
each_array { print $_[0], "\n" } (10,20,30);
`yield' just makes that a tiny bit easier, by working out which is
the coderef and calling it with the right thing:
sub each_array (&@) {
yield for @_;
}
`yield' will call the coderef with `$_' implicitly, or any arguments
you give it:
sub each_with_index (&@) {
yield ($_[$_], $_) for 0..$#_;
}
each_with_index { print "The $_[1]th element is $_[0]\n" } @stuff;
Note that this doesn't actually modify `@_': the coderef is still
`$_[0]', but `yield' attempts to avoid yielding onto itself. That is
to say, `yield' does nothing when the first argument passed is the
same as the coderef itself.
If you actually do want to call the coderef on itself, i) you're
weirder than I am, and ii) call it as something other than the first
argument:
yield ("dummy", $_) for @_;
will happily pass the coderef in.
NOTE
The module tries to do the right thing in all cases, and it does do
the right thing in the vast majority of cases. But like all
labour-saving devices, you give up a little bit of control to gain a
bit of convenience. So maybe it'll do the wrong thing in pathological
cases. Consider it karmic retribution.
SUPPORT
Beep... beep... this is a recorded announcement:
I've released this software because I find it useful, and I hope you
might too. But I am a being of finite time and I'd like to spend more
of it writing cool modules like this and less of it answering email,
so please excuse me if the support isn't as great as you'd like.
Nevertheless, there is a general discussion list for users of all my
modules, to be found at
http://lists.netthink.co.uk/listinfo/module-mayhem
If you have a problem with this module, someone there will probably
have it too.
AUTHOR
Simon Cozens, `simon@cpan.org'
SEE ALSO
ruby(1)