From pbowers at pobox.com Sun Mar 1 13:47:03 2015 From: pbowers at pobox.com (Peter Bowers) Date: Sun, 1 Mar 2015 20:47:03 +0100 Subject: [pmwiki-devel] Error suppression - best practice Message-ID: I see often in PmWiki core & recipes where errors are suppressed via @: if (@$foo['bar'])... Recently I was challenged pretty strongly that this was never a good practice. So... is it just preference & this guy was opinionated? Or is this an older way to do things & best practice is to not use this operator? -Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From 5ko at 5ko.fr Sun Mar 1 14:49:53 2015 From: 5ko at 5ko.fr (Petko Yotov) Date: Sun, 01 Mar 2015 21:49:53 +0100 Subject: [pmwiki-devel] Error suppression - best practice In-Reply-To: References: Message-ID: <3c47e71d1ceb6ccfb816edba69b4bafa@5ko.fr> "Challanged pretty strongly" with what arguments and sources, citations or references? Someone once challanged our use of apostrophes to wrap HTML attributes - which was extremely wrong, and we were amateurs, and we had to use double quotes instead. When I pointed to the W3C HTML and to the XHTML Transitional standards which allow the use of apostrophes, the person kept insisting that it was wrong. What can you reply to someone like this. http://php.net/manual/en/language.operators.errorcontrol.php Using this @ operator is very consise and the code stays short, readable and maintainable. Consider: if ( @$foo ) { } @$bar++; versus: if ( isset($foo) && $foo>'' ) { } if ( ! isset($bar) ) $bar = 1; else $bar++; (for global variables you can also use the function IsEnabled().) The use of the @ operator is somewhat slower than isset(), in my testings about 0.0000037 seconds per call (without bytecode compilation or memcache which would be much less). This is less than 4 microseconds. I'd trade these any day for more readable and maintainable code. Petko On 2015-03-01 20:47, Peter Bowers wrote: > I see often in PmWiki core & recipes where errors are suppressed via @: > > if (@$foo['bar'])... > > Recently I was challenged pretty strongly that this was never a good > practice. > > So... is it just preference & this guy was opinionated? Or is this an > older > way to do things & best practice is to not use this operator? From pmichaud at pobox.com Sun Mar 1 15:58:34 2015 From: pmichaud at pobox.com (Patrick R. Michaud) Date: Sun, 1 Mar 2015 15:58:34 -0600 Subject: [pmwiki-devel] Error suppression - best practice In-Reply-To: <3c47e71d1ceb6ccfb816edba69b4bafa@5ko.fr> References: <3c47e71d1ceb6ccfb816edba69b4bafa@5ko.fr> Message-ID: <20150301215834.GC6444@pmichaud.com> For me, the use of the '@' is a conscious choice, not sloppiness. Programming languages have to walk a fine line regarding the number and level of error messages that are generated. Many programming languages let things pass without warning or notice, which means that potential errors go undetected. But turn up the level of checking too high, and the programmer has to jump through hoops or write lots of extra code even when the supposed "error" isn't significant or is otherwise being handled. No matter where a language draws this line, there are instances where it falls on the wrong side of what the programmer wants/intends. PHP's "@" operator is a convenient way to say "I know what I'm doing, please don't bother me about it." My response to a comment like "@ is never a good practice" would be to ask how the person feels about "type conversion" operators in other languages such as C, C++, C#, etc. In these languages, a compiler will often complain if operands of the wrong type are being used; a programmer will use a "cast" or "type conversion" to tell the compiler "I really do intend to do this here" so that it won't complain. I view PHP's "@" operator as being in this same category of constructs; used properly, it lets the programmer inform the language translator that the standard error checking (whatever it happens to be) doesn't apply in the operation that follows. Pm On Sun, Mar 01, 2015 at 09:49:53PM +0100, Petko Yotov wrote: > "Challanged pretty strongly" with what arguments and sources, > citations or references? > > Someone once challanged our use of apostrophes to wrap HTML > attributes - which was extremely wrong, and we were amateurs, and we > had to use double quotes instead. When I pointed to the W3C HTML and > to the XHTML Transitional standards which allow the use of > apostrophes, the person kept insisting that it was wrong. What can > you reply to someone like this. > > http://php.net/manual/en/language.operators.errorcontrol.php > > Using this @ operator is very consise and the code stays short, > readable and maintainable. Consider: > > if ( @$foo ) { } > @$bar++; > > versus: > > if ( isset($foo) && $foo>'' ) { } > if ( ! isset($bar) ) $bar = 1; > else $bar++; > > (for global variables you can also use the function IsEnabled().) > > The use of the @ operator is somewhat slower than isset(), in my > testings about 0.0000037 seconds per call (without bytecode > compilation or memcache which would be much less). This is less than > 4 microseconds. I'd trade these any day for more readable and > maintainable code. > > Petko > > On 2015-03-01 20:47, Peter Bowers wrote: > >I see often in PmWiki core & recipes where errors are suppressed via @: > > > >if (@$foo['bar'])... > > > >Recently I was challenged pretty strongly that this was never a good > >practice. > > > >So... is it just preference & this guy was opinionated? Or is this > >an older > >way to do things & best practice is to not use this operator? > > > _______________________________________________ > pmwiki-devel mailing list > pmwiki-devel at pmichaud.com > http://www.pmichaud.com/mailman/listinfo/pmwiki-devel From pmwiki at russhosting.com Thu Mar 5 03:57:33 2015 From: pmwiki at russhosting.com (Russ) Date: Thu, 05 Mar 2015 04:57:33 -0500 Subject: [pmwiki-devel] SSL for specific pages Message-ID: <54F8288D.8060300@russhosting.com> I have a site with two pages (containing forms) that need to be handled via https ... is there an easy way in config.php or via per-page customizations to ensure the connections for those pages are made using https instead of http? (An SSL certificate is installed on the server, just wondering the easiest way to redirect the two specific wiki pages.) Thanks in advance, Russ