Re^3: What's so bad about &function(...)?

Then you're forcing the maintainers to memorize an operator precedence table to infer your meaning, instead of writing it explictly.

Notice the word "clarity" in my original sentence. You seem to have missed it the first time through. Or maybe you just didn't understand what I meant. Statements where a maintainer is forced to memorize precedence tables are NOT clear, and hence fall under my "clarity" caveat.

Comment on Re^3: What's so bad about &function(...)?

Replies are listed 'Best First'.
Re^4: What's so bad about &function(...)? by Anonymous Monk on Dec 08, 2005 at 16:35 UTC
Notice the word "clarity" in my original sentence. You seem to have missed it the first time through. Or maybe you just didn't understand what I meant. Statements where a maintainer is forced to memorize precedence tables are NOT clear, and hence fall under my "clarity" caveat. Sure, but to know if you've omitted the proper set of parenthesis, one still needs to refer to the table, or at least, the subset of it that you consider "clear". If you use parenthesis all the time, you don't need to do even that. Depending on how your notion of what "clear" operator precedence is compares to your maintainer's notion, this may or may not lead to actual "clarity". :-) -- Ytrew	[reply]
Re^5: What's so bad about &function(...)? by revdiablo (Prior) on Dec 08, 2005 at 17:02 UTC
Sure, but to know if you've omitted the proper set of parenthesis, one still needs to refer to the table, or at least, the subset of it that you consider "clear". Sure, but there are plenty of things that are common sense. Perl's precedence table is set up (for the most part) to follow the principle of least suprise. Consider the following: `my $x = $y * $z;` [download] Hopefully we can all agree that the precedence here is pretty clear. Adding parentheses to this statement seems counterproductive, wasteful, and downright ugly. If you use parenthesis all the time, you don't need to do even that. Well, then you're writing Perl with a Lisp dialect. Which is fine, but trying to convince me to do that is going to be unsuccessful to say the least. :-)	[reply] [d/l]