From: Neil R. <Nei...@rc...> - 2009-03-29 18:15:27
|
This may not be all that advanced to everyone, but some of it's interesting. http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/ (Sorry, I LIKE the ternary operator) Neil -- Nei...@rc... Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. -- Alan Kay |
From: Benjamin H. <ben...@gm...> - 2009-03-29 18:50:03
|
I don't buy the argument against the ternary operator either. Inline if/then logic is incredibly handy for being terse. Ben On Sun, Mar 29, 2009 at 1:15 PM, Neil Rest <Nei...@rc...> wrote: > This may not be all that advanced to everyone, but some of it's interesting. > http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/ > > > (Sorry, I LIKE the ternary operator) > > Neil > -- > Nei...@rc... > > Don't worry about what anybody else is going to do. The best way to > predict the future is to invent it. > -- Alan Kay > > > ------------------------------------------------------------------------------ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss > |
From: Jason R. <ja...@ho...> - 2009-03-30 17:47:58
|
Number 3 is a very good discussion. I think the right way to think about it is more than just initializing variables. Its an engineering mindset or coding method.. Maybe call it "code to fail".. But the principle is to make the exception the success case rather than the error case. This is how good, secure input validation is done, how firewall rules are usually done, etc. The basic example he provides: if (auth($username) == 'admin') { $admin = TRUE; } else { $admin = FALSE; } is rewritten as: $admin = FALSE; if (auth($username) == 'admin') { $admin = TRUE; } He then talks about more complex nesting of if/else, but thats not the point.. Its really about ensuring that only expected results survive the processing. so in a function like: function ValidateUser($UID) { $return=FALSE; // LOTS OF STUFF return $return; } If you forget something or something else changes in the environment its going to break rather than pass on unintended results.. He does touch on a good performance trade-off in exiting with a return as soon as a fatal test occurs, such as: if (isBlacklisted($username)) { return FALSE; } Number 5 is one of my biggest annoyances with PHP developers in that A LOT of them drop the brackets.. Its one of a short list of things I would kill dead in the language. ALWAYS USE BRACKETS! There are a large number of reasons but auto-code processing and readability or top of the list.. I disagree with Ben and agree with authors on Ternary operators. Terse is often bad for survivable code. And ternary operators are not easily understandable by people knew to a language (which if your code survives for more than a couple of years will inevitably happen). Terse is only good for people who are experts in both the specific application and the language when printing it out for a hand code review.. Coding conventions (no short tags, use curly brackets, no ternary operators, consisten case and naming conventions, etc. etc.) really help the poor intern who gets stuck doing maintenance on your code 5 years from now. Number 8 is a bad thing as a rule of thumb.. Frameworks can be good and can also be bad.. Its really situation dependent.. Thanks for passing this on Neil! Neil Rest wrote: > This may not be all that advanced to everyone, but some of it's interesting. > http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/ > > > (Sorry, I LIKE the ternary operator) > > Neil > -- > Nei...@rc... > > Don't worry about what anybody else is going to do. The best way to > predict the future is to invent it. > -- Alan Kay > > > ------------------------------------------------------------------------------ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss |
From: Arlo L. <ar...@ar...> - 2009-03-30 18:21:29
|
> Number 5 is one of my biggest annoyances with PHP developers in that A > LOT of them drop the brackets. Its one of a short list of things I > would kill dead in the language. I'll sign that petition! Cheers, -Arlo _______________________________ Arlo Leach 773.769.6106 http://arlomedia.com |
From: Wilfried S. <ws...@de...> - 2009-03-30 18:34:40
|
I often use ternary in my view code, it's just clean and easy for setting checkboxes, etc. Was hoping that http://wiki.php.net/rfc/ifsetor/s suggested "?:" would be accepted. On Mar 30, 2009, at 12:47 , Jason Rexilius wrote: > Number 3 is a very good discussion. I think the right way to think > about it is more than just initializing variables. Its an engineering > mindset or coding method.. Maybe call it "code to fail".. But the > principle is to make the exception the success case rather than the > error case. This is how good, secure input validation is done, how > firewall rules are usually done, etc. > > The basic example he provides: > > if (auth($username) == 'admin') { > $admin = TRUE; > } else { > $admin = FALSE; > } > > is rewritten as: > > $admin = FALSE; > if (auth($username) == 'admin') { > $admin = TRUE; > } > > He then talks about more complex nesting of if/else, but thats not the > point.. Its really about ensuring that only expected results survive > the processing. > > so in a function like: > > function ValidateUser($UID) { > > $return=FALSE; > > // LOTS OF STUFF > > return $return; > > } > > > If you forget something or something else changes in the environment > its > going to break rather than pass on unintended results.. > > He does touch on a good performance trade-off in exiting with a return > as soon as a fatal test occurs, such as: > > if (isBlacklisted($username)) { > return FALSE; > } > > > > > Number 5 is one of my biggest annoyances with PHP developers in that A > LOT of them drop the brackets.. Its one of a short list of things I > would kill dead in the language. ALWAYS USE BRACKETS! There are a > large number of reasons but auto-code processing and readability or > top > of the list.. > > > I disagree with Ben and agree with authors on Ternary operators. > Terse > is often bad for survivable code. And ternary operators are not > easily > understandable by people knew to a language (which if your code > survives > for more than a couple of years will inevitably happen). Terse is > only > good for people who are experts in both the specific application and > the > language when printing it out for a hand code review.. Coding > conventions (no short tags, use curly brackets, no ternary operators, > consisten case and naming conventions, etc. etc.) really help the poor > intern who gets stuck doing maintenance on your code 5 years from now. > > > Number 8 is a bad thing as a rule of thumb.. Frameworks can be good > and > can also be bad.. Its really situation dependent.. > > > > Thanks for passing this on Neil! > > > > > > > Neil Rest wrote: >> This may not be all that advanced to everyone, but some of it's >> interesting. >> http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/ >> >> >> (Sorry, I LIKE the ternary operator) >> >> Neil >> -- >> Nei...@rc... >> >> Don't worry about what anybody else is going to do. The best way to >> predict the future is to invent it. >> -- Alan Kay >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> chiPHPug-discuss mailing list >> chi...@li... >> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss > > ------------------------------------------------------------------------------ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss |
From: Jough D. <jou...@gm...> - 2009-03-30 20:28:56
|
On Mon, Mar 30, 2009 at 1:07 PM, Wilfried Schobeiri <ws...@de...> wrote: > Was hoping that http://wiki.php.net/rfc/ifsetor/s suggested "?:" would > be accepted. It was. You can short-circuit ternary operations in PHP 5.3: http://us2.php.net/ternary |
From: Jason R. <ja...@ho...> - 2009-03-30 20:47:29
|
The example they give on the man page is enlightening if you think about it from the point of view of some college kid who had java or .net classes and is learning PHP on the job doing maintenance on some legacy code base: <?php // Example usage for: Ternary Operator $action = (empty($_POST['action'])) ? 'default' : $_POST['action']; // The above is identical to this if/else statement if (empty($_POST['action'])) { $action = 'default'; } else { $action = $_POST['action']; } ?> While the ternary operation is shorter and more terse, the standard if/else method will be easier for them to follow. Again, its about survivable code not shortest code. In order to survive it has to live in the real world which often has people of various skill levels interacting with it over time.. But, I'm just a curmudgeon ;-) Jough Dempsey wrote: > On Mon, Mar 30, 2009 at 1:07 PM, Wilfried Schobeiri <ws...@de...> wrote: > >> Was hoping that http://wiki.php.net/rfc/ifsetor/s suggested "?:" would >> be accepted. > > It was. You can short-circuit ternary operations in PHP 5.3: > > http://us2.php.net/ternary > > ------------------------------------------------------------------------------ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss |
From: Wilfried S. <ws...@de...> - 2009-03-30 20:55:21
|
Which is why you only use it in your view, not in your biz logic. The goal is clean, short, and survivable. The example they have on the manpage there is awful... I'd consider that borderline obfuscation. On Mar 30, 2009, at 15:47 , Jason Rexilius wrote: > The example they give on the man page is enlightening if you think > about > it from the point of view of some college kid who had java or .net > classes and is learning PHP on the job doing maintenance on some > legacy > code base: > > <?php > // Example usage for: Ternary Operator > $action = (empty($_POST['action'])) ? 'default' : $_POST['action']; > > // The above is identical to this if/else statement > if (empty($_POST['action'])) { > $action = 'default'; > } else { > $action = $_POST['action']; > } > > ?> > > > While the ternary operation is shorter and more terse, the standard > if/else method will be easier for them to follow. > > > Again, its about survivable code not shortest code. In order to > survive > it has to live in the real world which often has people of various > skill > levels interacting with it over time.. > > But, I'm just a curmudgeon ;-) > > > > > > Jough Dempsey wrote: >> On Mon, Mar 30, 2009 at 1:07 PM, Wilfried Schobeiri <ws...@de... >> > wrote: >> >>> Was hoping that http://wiki.php.net/rfc/ifsetor/s suggested "?:" >>> would >>> be accepted. >> >> It was. You can short-circuit ternary operations in PHP 5.3: >> >> http://us2.php.net/ternary >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> chiPHPug-discuss mailing list >> chi...@li... >> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss > > ------------------------------------------------------------------------------ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss |
From: Jason R. <ja...@ho...> - 2009-03-30 21:02:06
|
Precisely the point. But the construct will more often be abused than not if its in the style guide.. Dont get me wrong, I love rough, sharp pointy edges that the smart developer can use to do tricky things with, but thats more of a code cosmetics issue than actual functionality. I guess we all have opinions on where to make trade-offs, eh? ;-) Wilfried Schobeiri wrote: > Which is why you only use it in your view, not in your biz logic. The > goal is clean, short, and survivable. The example they have on the > manpage there is awful... I'd consider that borderline obfuscation. > > On Mar 30, 2009, at 15:47 , Jason Rexilius wrote: > >> The example they give on the man page is enlightening if you think >> about >> it from the point of view of some college kid who had java or .net >> classes and is learning PHP on the job doing maintenance on some >> legacy >> code base: >> >> <?php >> // Example usage for: Ternary Operator >> $action = (empty($_POST['action'])) ? 'default' : $_POST['action']; >> >> // The above is identical to this if/else statement >> if (empty($_POST['action'])) { >> $action = 'default'; >> } else { >> $action = $_POST['action']; >> } >> >> ?> >> >> >> While the ternary operation is shorter and more terse, the standard >> if/else method will be easier for them to follow. >> >> >> Again, its about survivable code not shortest code. In order to >> survive >> it has to live in the real world which often has people of various >> skill >> levels interacting with it over time.. >> >> But, I'm just a curmudgeon ;-) >> >> >> >> >> >> Jough Dempsey wrote: >>> On Mon, Mar 30, 2009 at 1:07 PM, Wilfried Schobeiri <ws...@de... >>>> wrote: >>>> Was hoping that http://wiki.php.net/rfc/ifsetor/s suggested "?:" >>>> would >>>> be accepted. >>> It was. You can short-circuit ternary operations in PHP 5.3: >>> >>> http://us2.php.net/ternary >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> chiPHPug-discuss mailing list >>> chi...@li... >>> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss >> ------------------------------------------------------------------------------ >> _______________________________________________ >> chiPHPug-discuss mailing list >> chi...@li... >> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss > > > ------------------------------------------------------------------------------ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss |
From: Wilfried S. <ws...@de...> - 2009-03-30 20:59:38
|
Yay! I haven't been following the changelog on 5.3 very closely, only mysqlnd. On Mar 30, 2009, at 15:28 , Jough Dempsey wrote: > On Mon, Mar 30, 2009 at 1:07 PM, Wilfried Schobeiri <ws...@de... > > wrote: > >> Was hoping that http://wiki.php.net/rfc/ifsetor/s suggested "?:" >> would >> be accepted. > > It was. You can short-circuit ternary operations in PHP 5.3: > > http://us2.php.net/ternary > > ------------------------------------------------------------------------------ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss |
From: matt d. <mm_...@ya...> - 2009-03-30 20:03:44
|
The ternary sieve- $r = false; if(!$r)$r = (strpos($hub,"PRJ")>-1)? true:false; if(!$r)$r = (strpos($hub,"EAI")>-1)? true:false; if(!$r)$r = (strpos($hub,"ST")>-1)? true:false; if(!$r)$r = (strpos($hub,"PR")>-1)? true:false; ________________________________ From: Jason Rexilius <ja...@ho...> To: Chicago PHP User Group <chi...@li...> Sent: Monday, March 30, 2009 12:47:28 PM Subject: Re: [chiPHPug-discuss] "10 Advanced PHP Tips" Number 3 is a very good discussion. I think the right way to think about it is more than just initializing variables. Its an engineering mindset or coding method.. Maybe call it "code to fail".. But the principle is to make the exception the success case rather than the error case. This is how good, secure input validation is done, how firewall rules are usually done, etc. The basic example he provides: if (auth($username) == 'admin') { $admin = TRUE; } else { $admin = FALSE; } is rewritten as: $admin = FALSE; if (auth($username) == 'admin') { $admin = TRUE; } He then talks about more complex nesting of if/else, but thats not the point.. Its really about ensuring that only expected results survive the processing. so in a function like: function ValidateUser($UID) { $return=FALSE; // LOTS OF STUFF return $return; } If you forget something or something else changes in the environment its going to break rather than pass on unintended results.. He does touch on a good performance trade-off in exiting with a return as soon as a fatal test occurs, such as: if (isBlacklisted($username)) { return FALSE; } Number 5 is one of my biggest annoyances with PHP developers in that A LOT of them drop the brackets.. Its one of a short list of things I would kill dead in the language. ALWAYS USE BRACKETS! There are a large number of reasons but auto-code processing and readability or top of the list.. I disagree with Ben and agree with authors on Ternary operators. Terse is often bad for survivable code. And ternary operators are not easily understandable by people knew to a language (which if your code survives for more than a couple of years will inevitably happen). Terse is only good for people who are experts in both the specific application and the language when printing it out for a hand code review.. Coding conventions (no short tags, use curly brackets, no ternary operators, consisten case and naming conventions, etc. etc.) really help the poor intern who gets stuck doing maintenance on your code 5 years from now. Number 8 is a bad thing as a rule of thumb.. Frameworks can be good and can also be bad.. Its really situation dependent.. Thanks for passing this on Neil! Neil Rest wrote: > This may not be all that advanced to everyone, but some of it's interesting. > http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/ > > > (Sorry, I LIKE the ternary operator) > > Neil > -- > Nei...@rc... > > Don't worry about what anybody else is going to do. The best way to > predict the future is to invent it. > -- Alan Kay > > > ------------------------------------------------------------------------------ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss ------------------------------------------------------------------------------ _______________________________________________ chiPHPug-discuss mailing list chi...@li... https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss |