The Perl-talk was great. Those who missed it and have to deal with Perl, should urgently watch it. Keep your popcorn ready! :-)

In an earlier announcement he writes: "Um 22:00 verspricht der Perl-Vortrag hochkarätig zu werden." (At 22:00 the Perl lecture promises to be top-class.) Being an influential guy and to some extent spokesman for the CCC (although he dismisses that, his label is associated with the CCC) I judge that as intolerable.

I haven't seen the video yet, but I have to admit that meditating about fat comma was worth talking about it.

Your meditations are valid, but building an edge case for "fat comma" as it is, breaks orthogonality. Array context is array context, and that applies to %hash as LHS value.

> At 22:00 the Perl lecture promises to be top-class.

Which implies he didn't see it before. YAPC talks aren't vetted why should CCC talks be? Have you given a talk before?

And after attending some CCC meetings I'd been very surprised of such level of review by a heterogeneous group of chaotic punks who love to see themselves in the hacker image of Hollywood media.

> Array context is array context, and that applies to %hash as LHS value.

The context isn't fixed by the top statement which is the list-assignment to %hash .

That's why you can easily write

  DB<103> sub func { return 3,4,5 }

  DB<104> $href = {a => scalar func(), b => "x" }
 => { a => 5, b => "x" }
[download]

So again, why shouldn't => have a built-in scalar at RHS?

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

¹) maybe unfair, but I heard much harder stuff there... especially after reading fefe blogs :)

More to the point: the fat comma particularities apply to the LHS in any expression. The fat comma is just a comma. A comma in list context... yadda yadda, I won't expand that further. The RHS of a fat comma is already in list context, if the (fat) comma is a list operator.

qwurx [shmem] ~ > perl -le 'sub f{qw(foo bar baz)}$_=(f=>f);print'
baz
qwurx [shmem] ~ > perl -le 'sub f{qw(foo bar baz)}@_=(f=>f);print"@_"'
f foo bar baz
[download]

That's easy. Introducing scalar context to the RHS of the fat comma is just quirky IMHO.

Why should it be too hard to grasp that an array (or a function return which yields a list) expands into a list in list context?

The context isn't fixed by the top statement which is the list-assignment to %hash . That's why you can easily write DB<103> sub func { return 3,4,5 } DB<104> $href = {a => scalar func(), b => "x" } => { a => 5, b => "x" }

This is bull. The scalar in there does what? There.

In my book, the context of the (finally discarded) last value of an assignment is set up by the LHS. But then, I might be entirely wrong about context in perl.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Agreed: the presentatation was quite insolent, but not without merit. There was food for thought. Slides with code and camel mugshots on the left, video inset of Netanel wearing a camel scarf on the right. Charming. :D

Fat comma just implies a mapping relationship, and one-to-many is a possibility in the abstract sense. The problem is not limited to fat comma either. Consider: @k = qw(foo bar baz); @v = (1,bar(),3); %m = zip @k, @v;

Power/flexibility is a double-edged sword. No news here. I do wonder though — what if the CGI method had been named params all along? Would that have resulted in fewer thinkos?

Yeah, the problem is CGI::param() not DBI. I recall many times having to jump through extra hoops because I realized that param() might return more than one value (and I suspect there were times I didn't because I didn't). CGI::param()'s interface isn't "just" a trap for introducing bugs, it is also inconvenient. It is a bad interface, though the badness is somewhat subtle (which actually makes the problem worse, including not just fixing the interface long ago).

The general pattern is that it is fine for something that normally returns several things to, in a scalar context, return just the most interesting aspect of those things. It is a mistake to take something that normally returns just a scalar and create cases where it might return other than just a scalar. And that applies even if the function is documented as "returns all of the values for foo" but a very common case will be that you only expect or want one value "for foo".

Having the name be plural would have made the need to jump through hoops for the common case of just wanting one value more likely to be done. But it still would have been a bad interface.

A better interface would be more like:

sub get_params {
    ....
    return wantarray ? @vals : \@vals;
}

sub get_param {
    return get_params( @_ )->[-1];
}
[download]

But this is far from some fundamental problem with Perl. It is a bad practice to avoid, like can be found when you work with any language to enough depth. I find Perl actually has far fewer of these (and mostly less severe ones) than C or C++, for example.

- tye        

>

sub get_param {
    return get_params( @_ )->[-1];
}
[download]

If this is a feature request for CGI I'd like to see a setting to raise an exception if multiple values are received where only one value is legally expected.

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

Yeah, the problem is CGI::param() not DBI

Hmm, did you ever submit a bug report for that? :)

Speaking of this talk:

bugzilla doesn't even use CGI.pm, it uses Bugzilla::CGI ... if they went that far they could have fixed the API

movable type wasn't doing any argument validation while generating dynamic sql ... can't blame it on CGI

Is CGI.pm's actual interface the best? No, but its been that way for the past 20+ years and its using a common perl feature (context sensitivity) ...

but yeah, context sensitivity is just mental overhead that is easy to avoid

Finally I saw the video (against better knowledge that it will keep me awake... ;-)

Apart from the urgent need to kick this annoying kid into a pit full of pythons (snakes not hackers¹) I was very surprised about the DBI examples...

Because quote($$;$) has obviously a signature which should force scalar context.

I coded a little example...

use strict;
use warnings;


package DBI;
use Data::Dumper;

sub quote ($$;$) {
    print Dumper \@_;
}

package CGI;

sub param {
    return qw/a b c/;
}

package main;

DBI->quote(CGI->param());

#DBI::quote(CGI->param());
[download]

out

$VAR1 = [
          'DBI',
          'a',
          'b',
          'c'
        ];
[download]

It turns out that signatures are not effective when used as a method, b/c they can't be evaluated at compile time.

OTOH uncommenting the second direct call causes a compilation error.

The documentation of DBI is purely OOP demonstrating method calls...

... so what keeps me puzzled is why the $-signatures where ever inserted.

(It looks like it was originally not meant to be OOP and handling the problem ... but when switching to OOP this use case was forgotten.)

Does anyone have insights if this was addressed now by the maintainers?

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

PS: YES I'm aware that using placeholders is the state of the art now... though I could imagine someone still using such code in production.

¹) I'm not a sadist...

Could someone please help me find products proven to be vulnerable by using DBI->quote() ?

The only mentioned SQL injection in the talk was

CVE-2014-9057 – MovableType SQL Injection

But I couldn't find any details ... does anyone know the effected code?

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

> what if the CGI method had been named params all along

There is already another "params" method, this had been discussed in the mentioned bugzilla threads.

> The problem is not limited to fat comma either. Consider: @k = qw(foo bar baz); @v = (1,bar(),3); %m = zip @k, @v;

If it comes to "comma" and "list flattening" it's a feature not a problem!

I just used (something similar) again in another post (see (undef,my %hash)= ).

But IMHO implementing => as a "fat" version of comma was misleading, because even experienced Perl hackers expect a 1-to-1 relation, and Perl is supposed to DWIM.

NB Perl6's design has => as "pair-operator" not "fat comma" and the propagation of context into subs has been changed too.

But this is a language design thing which IS NOT a security problem as such.

IMHO HTTP-responses returning more than one value for a singular form-element should be sanitized from the beginning.

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

I am hereby notifying you of my intention to steal the term thinkosand use freely henceforth. Message ends.

FWIW, I think thinko predates perlmonks/2001 and its not trademarked :)

I'm not sure which backwards compatibility would break if => would force scalar context on the RHS.

Try Moose attribute initializers, especially if you use grouping parentheses.

> Try Moose attribute initializers, especially if you use grouping parentheses.

An example would have been nice ...

(... google ... google...)

I think you mean something like

    has pizza => (
        is     => 'ro',
        isa    => 'Pizza',
        writer => '_pizza',
    );
[download]

which is just syntactic sugar (sic) for

    has 'pizza' , 
        is     => 'ro',
        isa    => 'Pizza',
        writer => '_pizza',
    ;
[download]

and maybe should have been better designed as

    has pizza => {
        is     => 'ro',
        isa    => 'Pizza',
        writer => '_pizza',
    };
[download]

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

update

FWIW:

a new feature allowing to change => from "fat comma" to a kind of "pair operator" wouldn't effect Moose's has() w/o parens.

  DB<105> sub has { \@_}

  DB<106> has pizza => scalar 
                   is     => scalar 'ro'
 => ["pizza", "is", "ro"]
[download]

It's scalar(CODE) which enforces a scalar comma within CODE to only return the last element.

  DB<107> has pizza => scalar (
                   is     => scalar 'ro',
           );
 => ["pizza", "ro"]
[download]

OTOH a changed => doesn't necessarily need to act like a scalar comma.

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

Furthermore I'm not sure why HTTP responses aren't easily sanitized, such that fields which are not expected to hold multiple values are blocked/filtered before any further processing takes place.

For instance: Why should I even handle requests with multiple real_name ?

Hmm... odd thoughts