Re: [PHP-DEV] Portability concerns
On Saturday 04 August 2001 22:06, Stig Sæther Bakken wrote: Say PHP had a function to put it in portable mode changing the behaviour of a few functions. Then for example PEAR classes would have to deal with running both with and without this mode, since the user can enable or disable it at will. So this would in fact add complexity to the process of writing portable PHP code. No this isn't the case. You can drop in and out of this mode in your own code, so PEAR classes would switch into it and there would be no problem. I think André is right that it's better to educate users (for example by telling them to disable magic_quotes :-). I agree about the education bit as well, but I think it would be good to have a mechanism that help to future proof old code for when the rules changed. Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Portability concerns
[Phil Driscoll [EMAIL PROTECTED]] I was going to send a post on this topic yesterday, but then I deleted it, but maybe it is worth airing incase it prompts someone whose brain is working better than mine was yesterday to rifine the idea. My thought was that it may be possible to get rid of some of the portability issues by implementing a new function php_portability() which takes TRUE or FALSE arguments to turn it on or off. The idea is that when switched on, it could modify the behaviour of certain functions dependent on the php.ini settings - e.g. addslashes or stripslashes would do nothing if magic_quotes were on in php.ini and do its normal job if they were off. Sadly the above example is complicated by having magic_quotes_gpc and magic_quotes_runtime, so it may not be possible to sort out. The other reason I didn't post yesterday, was that I could not then think of any other functions for which this kind of behaviour would work :) With such a php_portability() function, it would be _even_ harder to write portable library code (because you need to handle both settings). Two wrongs won't make this one right. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Portability concerns
On Saturday 04 August 2001 08:49, Stig Sæther Bakken wrote: [Phil Driscoll [EMAIL PROTECTED]] With such a php_portability() function, it would be _even_ harder to write portable library code (because you need to handle both settings). Two wrongs won't make this one right. :-) Please explain! -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Portability concerns
-Original Message- [Phil Driscoll [EMAIL PROTECTED]] My thought was that it may be possible to get rid of some of the portability issues by implementing a new function php_portability() which takes TRUE or FALSE arguments to turn it on or off. The idea is that when switched on, it could modify the behaviour of certain functions dependent on the php.ini settings - e.g. addslashes or stripslashes would do nothing if magic_quotes were on in php.ini and do its normal job if they were off. Sadly the above example is complicated by having magic_quotes_gpc and magic_quotes_runtime, so it may not be possible to sort out. The other reason I didn't post yesterday, was that I could not then think of any other functions for which this kind of behaviour would work :) I don't like the idea of a function like this, I think it's much more important to educate people on how they write portable PHP code (to the extent possible). If the PHP community is going to continue flaunting PHP as a a portable language, the very same community must have guidelines on how to make it portable. Now, one of the reason that I post this is that even though I have been programming PHP for two years, and feel fairly proficient at it, I know very little about which settings are available and what they do (this has generally been handled by the syops I've been working with.) I don't think I'm alone at feeling a bit at loss when it comes to all the different options and settings and stuff that might make your script break if you upgrade, change server, or let someone else use them. So, what I would like to see is a nice set of guidelines -- W3C style -- on how to write portable PHP code. I think there are a lot of people out there who could benefit from a such document. André Næss -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Portability concerns
On Saturday 04 August 2001 15:03, André Næss wrote: I don't like the idea of a function like this, I think it's much more important to educate people on how they write portable PHP code (to the extent possible). That is my point really - what constitutes 'portable code' has changed quite a bit over the time I've been using PHP. I was hoping to provoke discussion of a mechanism whereby such changes might be made without breaking code, or changing the rules as to what constitutes portable code. Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Portability concerns
[Phil Driscoll [EMAIL PROTECTED]] On Saturday 04 August 2001 08:49, Stig Sæther Bakken wrote: [Phil Driscoll [EMAIL PROTECTED]] With such a php_portability() function, it would be _even_ harder to write portable library code (because you need to handle both settings). Two wrongs won't make this one right. :-) Please explain! Say PHP had a function to put it in portable mode changing the behaviour of a few functions. Then for example PEAR classes would have to deal with running both with and without this mode, since the user can enable or disable it at will. So this would in fact add complexity to the process of writing portable PHP code. I think André is right that it's better to educate users (for example by telling them to disable magic_quotes :-). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
