Does PHP have the equivalent of 'use strict;'?

Post #165,478 by ben_tilly 7/21/04 9:54:30 PM Reply	Does PHP have the equivalent of 'use strict;'? The (mis)feature that you describe is in Perl as well. There it is called "The Poetry Optimization". But Perl has the strict pragma that turns it off and flags barewords that aren't something else as syntax errors. Does PHP have any similar feature for avoiding targeting your own feet? The bigger lesson is that embedding if tests is the wrong way to go for compatibility. Read [link\|http://www.kerneltraffic.org/kernel-traffic/kt20000501_65.html#5\|http://www.kerneltra...0000501_65.html#5] and then apply the lesson to any other language you are in. The way that I do development switches is to have an initialization section that sets key variables (like which database to connect to) based on what environment you're in. It then connects to the database named in the variable. In this case that would have kept the code from successfully running in development, and therefore caught the error before it got into production. You also don't need to worry about whether someone slipped something important into an if condition and didn't duplicate it properly. That type of error just goes away. Cheers, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]
Post #165,487 by ChrisR 7/21/04 10:29:47 PM Reply	or Option Explicit for the VB world :-) Seems PHP doesn't have a use strict type thing but apparently you can set it to report it as an error during runtime: [link\|http://www.faqts.com/knowledge_base/view.phtml/aid/651/fid/38\|The closest thing to 'strict' in PHP is setting error_reporting to E_ALL.]
Post #165,509 by drewk 7/22/04 12:44:25 AM Reply	Trying to figure out how I can use this His solution is that when there needs to be a compatibility layer, it should be back-ported to the old code. We have a huge collection of code that is all effectively dynamically linked at run time. And no test cases or regression-testing scripts. Globally back-porting a change in the way we handle our DB environment would take weeks. (Not that I don't want to do it.) The problem we had today is because we are trying to move to a sane environment where all of our database connections[1] use the same environment. This case was just a poor implementation of the beginnings of a good idea. [1] Why "connections", plural? If you look through our older code, every function that needed a database connection created its own. Even functions that were executed inside of tight loops. If it weren't for the fact that PHP and MySQL conspire to recycle the same connection from one call to the next, we've got reports that attempt to create literally thousands of DB connections for a single page load. Now we pass around one connection per DB server. (Our version of MySQL doesn't do cross-server joins, so we still need one connection per box.) === Implicitly condoning stupidity since 2001.
Post #165,512 by ben_tilly 7/22/04 1:10:39 AM Reply	His solution is more general than that The basic solution can be read as, Decide the API that you want to program to, create a compatibility layer that supports that API for each platform, program to that compatibility layer. In the simple case the compatibility layer is trivially simple in one case. If you'll read [link\|http://www.oreilly.com/catalog/opensources/book/linus.html\|http://www.oreilly.c...s/book/linus.html] you'll note that the solution within Linux for how to support so many architectures takes this exact form, again. In this case you can follow a strategy like this (written in Perl, badly): `\n# A badly done compatibility layer.\nmy $DATABASE;\nif ($IS_DEVELOPMENT) {\n ...\n $DATABASE = 'DEV';\n ...\n}\nelse {\n ...\n $DATABASE = 'PROD';\n}\n\n# and outside of the compatbility layer...\nmy $dbh;\nsub open_connection {\n unless ($dbh) {\n # If somebody typoed, there will be no database\n # to connect to of the name this gets, and things\n # will (properly) blow up.\n $dbh = open_database($DATABASE);\n }\n return $dbh;\n}\n` Now the error that you had becomes very different. Getting the variable name wrong somewhere results in an instant highly visible crash. The flaws in how I've written this are many. For one thing you often want to support cascading defaults since many configuration variables should be the same in development and production. But cascading defaults open you up again to accidentally having something cascade that shouldn't. Therefore have both development and production cascade back to sane defaults. Most configuration items go into the defaults. The few that have to differ do not go into the defaults. For another you're likely to need at least 3 environments some day. (Development, staging, production.) Build that flexibility in. I've seen multiple ways of doing that. One of the better ones is to build up a hash of hashes. Each sub-hash is a possible configuration. The outer hash is a mapping of environment to configuration variables. In building it up, you make some sub-hashes start as copies of others - right there you have your cascading logic! That is very nice if you, for instance, want to give each developer their own machine with a customized installation to play with. But for all of its flaws, the above demonstrates the key idea. Have a section devoted to configuration information only. Then don't scatter if-tests around. Instead have other functions that act in a very generic way upon the configuration data. Cheers, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]
Post #166,233 by drewk 7/27/04 1:58:41 AM Reply	Finally had time to reply to this And the reply is, "Yeah, no shit." Then don't scatter if-tests around. The reason it was written this way is that the devel database is not actually a complete snapshot of live. Lots of tables and some whole databases aren't there, so pages break horribly in the devel environment. This should of course be solved by replicating the rest of the db. Instead it was handled by adding a configuration option to the db class to over-ride devel mode and connect to the live server anyway. So the developer then had to track, "For this function I want a connection to the live db, for that function I want a connection to devel." That stops now. Devel is devel, and if it doesn't work in devel then you fucking fix it. For another you're likely to need at least 3 environments some day. (Development, staging, production.) ... That is very nice if you, for instance, want to give each developer their own machine with a customized installation to play with. Actually we've got four: Devel, where each developer has his own vhost and all db connections (starting tomorrow morning) are to the devel db. Stage, for testing (assuming we hire some testers [sub-rant deleted here]), which also (as of tomrrow morning) points to devel db. Cert, for QA (assuming we hire ... oh, I already went there) which points to live data. Live. === Implicitly condoning stupidity since 2001.
Post #166,234 by deSitter 7/27/04 2:04:24 AM Reply	Re: Finally had time to reply to this The thing is, devel needs full-time attention like live, and it never gets that, because it's junk (not really, but...) -drl
Post #166,369 by ben_tilly 7/27/04 8:10:11 PM Reply	That's backwards :-( The reason it was written this way is that the devel database is not actually a complete snapshot of live. Lots of tables and some whole databases aren't there, so pages break horribly in the devel environment. This should of course be solved by replicating the rest of the db... It sounds like changes have been made directly on live and never propagated back. Which means that you're walking on a highwire twice. Of course the way that you should do it is write scripts to update dev, and then when you're happy, run them against prod. That way dev either matches prod or is ahead of it. (Data, of course, gets copied from time to time from prod to dev.) But you know that. Convincing the rest of the company is your problem... Cheers, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]
Post #166,451 by drewk 7/28/04 9:32:26 AM Reply	Gosh, really? Remember, we didn't have a devel DB until recently. Building a new one from scratch takes one of our report servers out of the rotation for most of a day, so we've been copying stuff "as needed". Our other problem is that the one person who has access to make changes on the live DBs doesn't use the devel DBs at all. === Implicitly condoning stupidity since 2001.
Post #166,458 by ben_tilly 7/28/04 11:35:00 AM Reply	Gah. I wish that was unusual. :-( To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]

Welcome to IWETHEY!