Re: Re: cvs: php4/ext/odbc php_odbc.c

Andi, Sounds like a good option, but I'm not entirely sure how one would do that in the PHP environment. Open to suggestions :) On Wed, 6 Mar 2002, Andi Gutmans wrote: > That just shows how senile I am :) > Is there any way to check if the PHP developer is trying to send the > arguments in the old way and print out an E_WARNING telling him the > function proto has changed and how to fix it? (Just for a couple of versions) > > Andi > > At 19:07 05/03/2002 -0500, Dan Kalowsky wrote: > >Andi, > > > >This patch was initially ment to be applied for the 4.1 system. You and I > >had spoken at the time (I believe about 4.0.5) about this very patch > >(because I had made use of some screwy misuse of a Zend macro). We > >both agreed that variable order was wrong and should be corrected. It was > >under your urging that I wait until a semi-major version upgrade to make > >the change (at that time 4.1). Due to unforseen circumstances, I missed > >making the patch for 4.1, and have since waited for 4.2 thinking that was > >a major enough of an upgrade. If you feel otherwise, it can be taken > >out. I had just figured 4.2 was a major enough update that it sould go > >in. There had been a message in the TODO about doing this for awhile, but > >I see it's been taken out sometime without my notice. :\ > > > >Personally, I find it annoying, inconsistent, and confusing with the rest > >of the PHP behavior to have a (required, not required, required) variable > >order. > > > >I did place a note in the PHP documentation awhile back (according > >Jani/cvs in June 2001) warning users this function was to change. In fact > >the documentation specifically states "In PHP 4.1, this function will be > >moved to the following format..." Guess I fibbed just a bit. > > > >This should also return functionality that many users have requested which is > >odbc_fetch_into($result, $rArray, $row_num++) capability, but I haven't > >had a chance to test that yet... my ODBC datasource is MIA at the moment. > > > >I do not disagree though that this will burn users of the odbc_fetch_into > >functionality. Actually on more careful consideration, it won't effect > >all the users of it... only those that use the 3 variable form of the > >function really. I still tend to believe the pros outweight the cons. > > > >Pros: > >Consistency with all PHP function variable arguements > >Return of incrementing capability to pass row_number as a constant. > > > >Cons: > >Breaks BC from pre-4.0.6. > > > > > >If you have any others to list, please add them to the list. > > > > >---------------------------------------------------------------< > >Dan Kalowsky "Tonight I think I'll walk alone. > >http://www.deadmime.org/~dank I'll find soul as I go > >home." > >dank@deadmime.org - "Temptation", New Order > > > > > >-- > >PHP CVS Mailing List (http://www.php.net/) > >To unsubscribe, visit: http://www.php.net/unsub.php > >---------------------------------------------------------------< Dan Kalowsky "Tonight I think I'll walk alone. http://www.deadmime.org/~dank I'll find soul as I go home." dank@deadmime.org - "Temptation", New Order