Re: perldoc improvements for map

Front page | perl.perl5.porters | Postings from February 2011

Re: perldoc improvements for map

Thread Previous | Thread Next

From:

Tom Christiansen

Date:

February 13, 2011 06:56

Subject:

Re: perldoc improvements for map

Message ID:

11505.1297608966@chthon

David Golden wrote:

> (2) Security.  I think it is appropriate to recommend more
>     secure ways of doing things, such as three-argument open()

That depends on what you're doing.  Having to special-case every program
that needs it the myriad times you want "-" to mean the default thing
(but usually stdin) is as major a flaw as not having the shell expand
wildcards. You cannot expect every program to do this for itself or
failure; therefore magic open (and by extension, magic ARGV) is useful
in a significant set of situations.  Leaving things up to the programmer
to remember to do right is never a win, but the ternary-open people have
forgotten this important lesson with regard to reasonable defaults and
the Unix filter style of stream processing.

>(4) When there is a clear "old way" and "new way" and the old
>    way has clear downsides, but the old way has not been
>    deprecated for the sake of backwards compatibility.

I'd add the single-tick package separator to that list.

Probably also unquoted and/or backslashed heredoc tokens.

>    Bareword global filehandles might fall into this category.

Perfectly reasonable symbol-as-filehandle example:

    printf STDERR "%s: %s\n", basename($0), $msg;

>    Indirect object notation could be a close second, but I
>    suspect would be more debatable.

Perfectly reasonable dative (but not indirect) notation example:

    printf STDERR "%s: %s\n", basename($0), $msg;

Yes, those are intended to be the same.   

Here's a dative notation that is indeed indirect:

    $fh = \*STDERR;
    printf $fh "%s: %s\n", basename($0), $msg;

While here's one that is probably not perfectly reasonable:

    printf { $ok ? STDOUT : STDERR } "%s: %s\n", basename($0), $msg;

Here's another perfectly reasonable dative (but not indirect) 
notation example:

    @sorted = sort exquisitely @list;

Here is the same dative syntax, this time used indirectly:

    $adverb = \&exquisitely;
    @sorted = sort $adverb @list;

In which case it's probably not a dative, but more of 
an ablative or instrumental.  But anyway.  

My major point is that dative notation is well established in
Perl culture.

My minor point is that dative objects and indirect object are
actually different things altogether.  This is dative and direct:

    $object = new Frobniz:: "a" .. "z";

Whereas this is dative and indirect:

    $invocant = Frobniz::;
    $object   = new $invocant "a" .. "z";

While this is also indirect, but not dative:

    $invocant = Frobniz::;
    $object   = $invocant->new("a" .. "z");

Because this is direct and not dative:

    $object   = Frobniz::->new("a" .. "z");

although most people use the still-ambiguous:

    $object   = Frobniz->new("a" .. "z");

Finally, here is something of a double-indirect 
yet still wholly non-dative method invocation:

    $invocant = Frobniz::;
    $method   = $invocant->can("new");
    $object   = $invocant->$method("a" .. "z");

--tom

Thread Previous | Thread Next