Good to hear from you again David,
On Wednesday, April 3, 2002, at 06:28 AM, DL Neil wrote: > If they are one and the same machine/server, then use 'debug' code to > reset options at the beginning of dev code (and remove it when the > routine is 'promoted' to prod). Excellent idea. E_ALL for me from now on in development, ERROR_REPORTING: 0 in the php.ini. Whoah -- dozens of errors at the top of my scripts now. I'm going to have to do some research just to find out what all these undefined indexes and variables are all about. > In strongly typed languages, I think there are (?have been historically) > two objectives in defining variables prior to their use: > 1 to set aside the storage space, and > 2 to define the variable type > > 1 in the case of a scalar variable this seems trivial, eg > INTEGER J > Dim intJ As Integer > > In the case of an array or var/set length string, then replication needs > to be added into the equation for calculating both an individual > component's address and working out how much storage to set aside, eg > INTEGER K(10) > > 2 Somewhat obviously a double-precision floating point number will > require more space/bytes to store its value than a simple integer. > However a common error made when programming is that you think a > variable holds data of a certain type, when in fact you earlier used it > in some other (very similar, but not quite the same) manner. eg > > //don't use this code > $User = "Fred"; > later on we do (say) a db call and pull out a row of personal data: > $query = "SELECT * FROM persTbl WHERE persId = '$User' "; > //I'm assuming that persId is likely some sort of personnel/membership > number > > PHP is a 'little ripper' when it comes to quick and dirty usage, because > you don't have to type a declaration line before using a > variable/assigning storage (per part (1)) - PHP works it out for > you/from context, so it can 'very fast' (from a coder's point of view). > However such does leave one open to the problems described in part (2) - > which a strongly typed language would flag as an error! To this end, > some people decide to describe the usage of each variable as part of the > name. For example I was reading some Microsoft Excel macro/VBA stuff and > there's talk of intCounter and txtNameEntered - for an integer value and > the contents of a data-entry form's text box (resp). This seems like good advice, and I also try to be as descriptive as possible. Most of my variable names are at least ten characters long -- not necessarily quick to type, but then I type reasonably quickly and it's better for me to have $input_number_invalid = "<p>Bad input</p>" than $error (even though you rarely see a variable name that's longer than the string it represents!) > You have gone on to describe how the PHP attitude to typing enables the > creation of dynamic variables/variable names. This is a really powerful > feature, and has an important place in certain functions. However it is > not something I would put into an intro tutorial, because with such > power comes the potential to greatly expand the size of feet before > bringing them into close proximity with one's mouth! I agree wholeheartedly. And as another person on this list pointed out, arrays often will do the job much more efficiently (as there are plenty of functions that can let you do various tricks upon arrays). In this case, I needed to generate unique names for HTML form fields, so I had to use this hackish method -- I ended up with names like person1, person2, address1, address2, etc. > One of your correspondents pointed out that a really good compromise is > the associative array - the variable name (array name) stays 'constant', > but the array argument/pointer can be almost anything as a 'label'. As > another aside, it is also an 'advance' to know that the various contents > of an array in PHP do not have to be all the same datatype (as they > do/did in other languages)! Thus: > > $aPersRow[ "persId" ] = 12345; //integer > $aPersRow[ "persNm" ] = "Fred"; //string > $aPersRow[ "persDoB" ] = "1970-01-01"; //date And, having just gotten comfortable with classes and objects, I'm wondering if arrays can contain object references as well -- but I have already asked this on this list. Steve Cayford pointed out that objects work as expected for the most part with the exception of chained method calls and to be careful with passing by reference vs copy, which is useful information. > In PHP I have found it helpful to do something similar to the M$ > conventions mentioned earlier. I have set myself a set of 'naming > conventions' for PHP to help accommodate the power of dynamic typing, > whilst avoiding the potential traps. Here is a range I've grabbed from > some code I've just been working on: > > $iFrequency = 123; //is an integer > $aCounter = array( > "RowsAdded" => 0, ... ); //is an assoc array (of counters, > as described earlier) > $dBirth = "1970-01-01"; //is a date > $bValidity = MySQLdbUpdate( ... ); // is a boolean (TRUE/FALSE value) > $dbConnection //is a PHP/MySQL resource > SMTP_SERVER //is a PHP constant > $ColumnsClause = "PHASE, SEARCH, URL, FREQ"; //a variable name without > a 'prefix' is a string This is such a good idea. I would immediately adopt it but for the need to keep my code consistent in my current project, so perhaps it would be better to wait until my next project before I go about changing my conventions. Then again, I just went through (ONE FINAL TIME! :) and changed all of my date-related columns from VARCHAR(20) containing mktime() timestamps to DATE and DATETIME columns -- Rasmus Lerdorf made the point that I can easily convert from a timestamp back to MySQL's DATETIME or DATE (or any other) format, so why not just use the columns designed for keeping track of the time? Then I disabled magic_quotes_gpc and added addslashes() all over my code, at Miguel Cruz's suggestion, which also seems like a move toward better control. Why not just go through my scripts and change the variable names? > From memory the people who really get into standards for writing in PHP > in a big way are the PEAR project boys. I think there's some follow-up > reading there. > > Discussion/other ideas welcome! > =dn I'm going to try my best to get rid of those error messages (without resorting to removing the error_reporting(E_ALL)!), but I think that at least in the case of those dynamically-generated variables, it won't be possible. Thank you for your thoughts on this subject. Erik -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
