develooper Front page | perl.perl5.porters | Postings from December 2001

Importing Considered Harmful

Thread Next
From:
Jeffrey Friedl
Date:
December 19, 2001 19:14
Subject:
Importing Considered Harmful
Message ID:
200112200313.fBK3Dwd36624@ventrue.corp.yahoo.com

This is something that could deteriorate into a religious war, and I hope
it doesn't, but since I don't recall having seen it discussed before, I
thought I'd create the opportunity for that war.... :-)

Generally speaking, I think it's P^5 (Particularly Poor Perl Programming
Practice) to import functions into your namespace, and I think the perl
core docs and libraries should not encourage it, as they do now.

For example, perluniintro gives the example:

    use Encode 'from_to';
    from_to($data, "iso-8859-3", "utf-8"); # from legacy to utf-8

I think we should represent that example as

    use Encode;
    Encode::from_to($data, "iso-8859-3", "utf-8"); # from legacy to utf-8

because in practice, the 'use' and the 'from_to' will be separated in space
by an unknown amount of code, and in the programmer's mind by an unknown
amount of time, and the code-reader's mind by an unknown amount of
ignorance.

Perl already has more than its share of magic stuff to know, and increasing
the number of not-fully-qualified words in code just makes more magic.

When reading random code (perhaps code you're trying to learn from as
an example, or perhaps code you've been told to maintain), if you run
across something like:

        upgrade($a, $i, [ $x/2, $x*2 ]);

and you need to figure out what "upgrade" does, it's usually helpful to
know where it's defined. If you're lucky enough to have an explicit import
at the top of the file, as with the Encode example, it'll at least be
easier to find than if it didn't (in which case only magical knowledge of
where it's defined will help you.)

But had that reference been

    JeffsCrapyModule::upgrade($a, $i, [ $x/2, $x*2 ]);

you would have been hampered only by the complexity of $ENV{PERL5_LIB}.

Now, if you're reading this, you're probably an expert with Perl, so
you'll have no trouble when you see unadorned references to

       longmess
       filter_read_exact
       encode_qp
       test_f
       look
       colored
       parse_line
       fastgetcwd
       ungensym
       unlock

and you'll know exactly where to find documentation. But a non-expert
might not realize that
      longmess
is really
      Carp::longmess


I'm not saying that we should start using
    if (...) {
       Carp::carp("some error");
    }

because some things are so ubiquitous (or should be) that one can assume
that minimum knowledge. But as the core gets bigger and bigger and bigger,
I think there comes a point at when you should stop placing the burdon on
the reader to know everything. The result is more verbosity, yes, but I
think the reduction in magic is worth it.

It's not so painfully verbose to occationally see Data::Dumper::Dumper()
instead of just Dumper(), but if you have no idea what 'Dumper()' is,
seeing the fully-qualified name is much more understandable.

Thoughts?

        Jeffrey

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About