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

use Perl Log In

Log In

[ Create a new account ]

Journal of phaylon (6115)

Friday September 28, 2007
09:35 AM

My take on the Perl vs. Python code

A small follow up to chromatic

I'm always amazed that people who don't write Perl try to compare their Perl code to their $favorite_language code. I sometimes have a really hard time not writing a satirical essay where I try to write Python (where I have zero experience) and compare it to my Perl (which I write for a living).

Since the original author just threw together examples of what he doesn't like about Perl in a mostly non-consistent manner it isn't really an example and it doesn't make sense to me to try to translate it 1:1.

So, anyway, here's my take on the corrected version (I have left out the stuff that wouldn't compile):

# this simple line prevents globals in a
# file-wide scope. Might not be that nice, but if
# you're having problems with _that_, you should
# probably focus more on the problem you're
# actually trying to solve.
use strict;

sub func {
    my ($x, $array) = @_;

    # this must be as YUCK in Perl as in Python,
    # since they are doing the same thing.
    $array->[0] = 4;
    # UPDATE: I think I just got it. The original
    # author seems to complain that arrays aren't
    # references _by_default_ in Perl. Since you
    # can just use [] and therefor have the choice
    # in Perl (but not in Python as it seems),
    # this is IMO one more point for Perl.

    # this too works in Perl as in Python. A fact
    # that the original author obviously didn't
    # like, so he just wrote ++$x.
    $x += 1;

    print "$x\n";
    return 1;
}

my $i      = 1;
my $newvar = 'abc';
my @array  = (1, 2);

# this is another thing I don't get. Passing the
# array by reference in Perl is ugly, but it's
# fine in Python?
my $x = func(1, \@array);

print "$newvar\n";
print "i = $i\n";

$array[1] = 0;

# the original author seems to think here it
# should be that print $x, $y; should join the
# two with a whitespace. Well, I don't. We have
# the rather nice
print "@array\n"; # prints 4 0

I want to close with the notion that I would actually be interested in looking into a bit of Ruby and Python. But I feel the community supporting a language is important, if not more important than the language itself (Otherwise I'd be writing Scheme until you couldn't read the parenthesis on my keyboard anymore). And I really, really don't like what I see in the Ruby and the Python communities. While one might (correctly) argue that the core communities probably are more mature, they aren't that loud and it just seems too unprofessional to me.

Monday February 19, 2007
06:00 PM

namespace::clean off to the CPAN

Yesterday (at least I think it was yesterday, excuse the laziness) I released a pragma called namespace::clean. The short explanation for what this module does is this: When use'd, it will build a list of current functions in the package, and install a handler to call after the requesting modules compile time (via Filter::EOF) in which it removes those entries from the symbol table.

The long explanation is that you can import functions into your namespace, or even declare your own functions, that won't show up as methods on calls on your classes and instances. Previously, it always felt ugly to me to import functions (read: Carp, aliased, Scalar::Util & Co, ...) into a packages namespace, so I called them by their full name, for example, Scalar::Util::weaken(). The same ugliness overwhelms me everytime I put (proper documented) functions in OO packages, so a lot of them end up as methods, even if they don't need to. That's where this module joins the game.

Here is a simple demonstration: Let's define a usual object oriented class:

package Foo;
use warnings;
use strict;

use Carp qw( croak );

sub double {
    my $number = shift;
    return $number * 2;
}

sub new {
    my ($class, $number) = @_;
    bless {number => double($number)}, $class;
}

1;

This package will contain three functions: croak, double and new. But we actually just want new available as a method. Not because of coworkers, since they should refer to the hopefully complete and well written documentation, but to prevent conflicts with sub- and future base-classes.

Anyway, after compile-time the calls to the functions are already bound in the code and the actual symbol table entries aren't needed anymore. So we put a line reading use namespace::clean; in our code at the position where all the functions to remove are defined:

package Foo;
use warnings;
use strict;

use Carp qw( croak );

sub double {
    my $number = shift;
    return $number * 2;
}

use namespace::clean;

sub new {
    my ($class, $number) = @_;
    bless {number => double($number)}, $class;
}

1;

After this, the following will work correctly:

my $foo = Foo->new(23);
print $foo->{number}; # prints 46

But these will both return undef:

my $can_double = $foo->can('double');
my $can_croak  = $foo->can('croak');

So, that's it. I'd very much appreciate some comments. I'm currently thinking about no namespace::clean; and unimport magick for being able to build excludable parts.

Update: 0.02 has just entered the PAUSE and will be available soon.