Re: RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Naming changes.

James Moore wrote: > Another option we should look at is having the following in configure > --compat-mode /* depreciated functions issue notices */ > --strict-mode /* depreciated functions dont work at all */ > then when developing new stuff (ie on dev servers) people should use > strict-mode but on production servers --compat-mode should be used > (especially by ISP's and the like) This would imply that a another compile is required to work with two modes, (using two binaries for single server folks) and that RPM/.deb/whatever users (any user of externally compiled/setup binaries) would have to locate the "proper" one, adding to the "I tried an rpm install"... bug reports. On a different note, don't we already have something we can build the aging process/warning on, rather than inventing a new set of systems, and procedures, and documentation, and rulesets? (As these discussions seem to be doing, and adding to the general workload is usually a Bad Thing (tm)) We already have a capable warning system, are there sound reasons to add anything to PHP besides E_NOTICE then E_WARNINGs on the old names? Users can just change their error_reporting() in their .ini and/or on a per page, or per-script (or per function!) basis... one day, it will still fail, but they were warned. Is there a reason to offer an option to _enforce_ failure ahead of time, or treat these errors any differently than any other errors? It seems simple enough to add *only two* macros for deprecated aliases: PHP_OLDFALIAS_NOTICE PHP_OLDFALIAS_WARNING Both use a single message (no complex system, it's going away, no need for debate, no confusion about what's happening): (The function "" on line "" has been deprecated) We use comments (or CVS) for what revision/date... example: ---mysql.c, changed today, future aliases get changed when deprecated /* for downwards compatability, NOTICE 4.0.4 12/29/2000 */ PHP_OLDFALIAS_NOTICE(mysql, mysql_db_query, NULL) PHP_OLDFALIAS_NOTICE(mysql_fieldname, mysql_field_name, NULL) --- ---mysql.c, in a year(?) /* for downwards compatability, NOTICE 4.0.4 12/29/2000, WARN 4.0.12 12/18/2000 */ PHP_OLDFALIAS_WARNING(mysql, mysql_db_query, NULL) PHP_OLDFALIAS_WARNING(mysql_fieldname, mysql_field_name, NULL) --- And then delete them as the developer desires, later. 1. This would be easier than making new macros for each revision, PHP_FALIAS_401(), PHP_FALIAS_402(), so we have less to debug for compiles, for macro typos, etc. 2. It keeps deprecation info in an easy to change/maintain fashion. 3. It allows the different code maintainers to decide *when* to increase their levels and delete the aliases, so it's flexible for both heavily used, and rarely used, functions. 4. The end-users still get control of errors via reporting levels. 5. We warn them ahead of time, in a gradual fashion. 6. Most Importantly: We don't add compile options, ini options, new macros for release versions, or much else to maintain and document, as we use the same general system that already works, is already documented, and that the users already manage.... Only two macros, and some developer notes to let them know about the macros. Too simple? Too complex? -Ronabop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head.