How is a prototype of just @ a feature?

lodin

Because it allows me to write code like my @foo = map { [whatever] } uniq @arr1, uniq @arr2; With the prototype, this parses to uniq(@arr1), uniq(@arr2);. Without the prototype, this parses to uniq(@arr1, uniq(@arr2));. See the difference?

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Nope, you need "\@" for that.

That sounds weird. Which perl are you using? For all I know, that difference in parsing shouldn't happen.

lodin

Why not just uniqify both arrays with one uniq?

perl -MO=Deparse -MList::MoreUtils=uniq -e '
   @arr1=(1,2,1); @arr2=(2,3,3);
   my @foo = map { $_ } uniq @arr1, @arr2; 
   print @foo
'
use List::MoreUtils (split(/,/, 'uniq', 0));
@arr1 = (1, 2, 1);
@arr2 = (2, 3, 3);
my(@foo) = map({$_;} uniq(@arr1, @arr2));
print @foo;
-e syntax OK
[download]

perl -MList::MoreUtils=uniq -e '
   @arr1=(1,2,1); 
   @arr2=(2,3,3);
   my @foo = map {$_ } uniq @arr1, @arr2;
   print @foo
'
123
[download]

---

print+qq(\L@{[ref\&@]}@{['@'x7^'!#2/"!4']});

So, we are advocating the use of prototypes now are we?

What about the age old FMTEYEWTK about Prototypes? And I wonder what PBP and Perl::Critic would have to say about that?

Prototypes aren't bad. They're just a heck of a lot of rope by which one can hang oneself. I certainly wouldn't want to use them, but they have their uses. Kinda like symbolic references. There's some code that can't be written without them (like Exporter), but that doesn't mean most people should use them.

My rule of thumb is unless you know why you should never use them, you should never use them.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

The crux with prototypes is that they aren't, as you know. But some constructs aren't possible without them - see Embedding a mini-language for XML construction into Perl (and Re: Perl module for RELAX NG?). Those are the only "prototypes" I use now and then - function "prototypes".

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

It's a matter of record that I don't have a problem with using prototypes--nor most of the other oft-deprecated features of Perl-- when they facilitate something I cannot achieve without them, or improve the utility of function in use.

I do have a problem with them being used to justify the List::MoreUtils::uniq as 'better' than a throw-away "naive" definition of the same function.

1. because it would be trivial to add the prototype to the naive definition.
2. because the ability to do ... uniq @arr1, uniq @arr2; as opposed to ... uniq( @arr1 ), uniq( @arr2 ); rates about -10 on my scale of desirable features for that sub.

Just another justifiction in my opinion.

The "retains original ordering" argument can be a good one, if you need that facility, and unlike the "properly handles overloaded stringification" argument, it doesn't appear to have any downsides. Though I have to agree with lodin that for a module that "was worked over by many people over several years", even if you believe it's semantics are correct or 'best', it's implementation is far from perfect.

Don't misinterpret that. I think List::MoreUtils is one of the most useful modules on cpan, but in the context of this thread, the justifictions for using it are weak to say the least.

Like the OP, I have a problem with replacing one line of 'native Perl' with a module and two lines of native Perl. Especially when the module imparts it's own flavour to the functionality, that whilst may be "better" for some situations, can be detrimental for others. And by using it, one is removed from the flexibility to tailor the code to actual requirements of the situation. As I demonstrated here through reducio ad absurdum, the replacing one line of Perl with 2 lines of Perl in the name of code reuse is, ... well, absurd.

And I have a big problem with the idea that utilising code from CPAN always reduces ones workload; or future-proofs ones code; or lessens ones responsibilities for bugs. It is equally flawed. CPAN contains a huge amount of really great code that I can use for the effort of a few minutes installation, and that I could never reproduce myself.

But it also contains a large amount of dross. And as I've discovered to my cost recently, who wrote it is not a perfect indicator of the quality of either the design, the implementation or the support you will receive. An observation that holds double if you use a non-POSIX platform.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."