Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » implicit_clone »

implicit_clone

php.internals

Sterling Hughes

23 years ago
Hi, Currently, soley for backwards compatibility purposes we provide the ze2.implicit_clone option. This option is globally settable, and may be used by shared hosting providers to make it more likely that old scripts can run unmodified. This however makes it extremely hard, and inelegant for people relying on new "functionality" in php5 to write portable php5 scripts. More specifically, it would require every portable script to do: ini_set('ze2.implicit_clone', 0); At the top of their script. I think we should remove this ini option in favor of a function that does the same thing. This way implicit_clone() is not globally settable, but is settable per script. Something in the way of a: pragma_set('implicit_clone', true); Which would turn on implicit_clone for the current script (current portion of code.) -Sterling
-- "A business that makes nothing but money is a poor kind of business." - Henry Ford

Martin Jansen

23 years ago
On Sun Jun 22, 2003 at 01:5924PM -0400, Sterling Hughes wrote:
> I think we should remove this ini option in favor of a function that > does the same thing. This way implicit_clone() is not globally > settable, but is settable per script. Something in the way of a: > > pragma_set('implicit_clone', true); > > Which would turn on implicit_clone for the current script (current > portion of code.)
Sounds like a good idea for me, especially when taking into account that pragma_set() can be called within a auto_prepend-file, which makes it pretty easy to add "backwards compatibility" to a whole project without much work.
-- - Martin Martin Jansen http://martinjansen.com/

Moriyoshi Koizumi

23 years ago
Sterling Hughes <sterling@bumblebury.com> wrote:
> I think we should remove this ini option in favor of a function that > does the same thing. This way implicit_clone() is not globally > settable, but is settable per script. Something in the way of a: > > pragma_set('implicit_clone', true); > > Which would turn on implicit_clone for the current script (current > portion of code.) >
How about using "declare" statement? Moriyoshi

Zeev Suraski

23 years ago
At 20:59 22/06/2003, Sterling Hughes wrote:
>hi, > >currently, soley for backwards compatibility purposes we provide the >ze2.implicit_clone option. this option is globally settable, and may be >used by shared hosting providers to make it more likely that old scripts >can run unmodified. this however makes it extremely hard, and inelegant >for people relying on new "functionality" in php5 to write portable php5 >scripts. more specifically, it would require every portable script to >do: > >ini_set('ze2.implicit_clone', 0); > >at the top of their script. > >i think we should remove this ini option in favor of a function that >does the same thing. this way implicit_clone() is not globally >settable, but is settable per script. something in the way of a: > >pragma_set('implicit_clone', true); > >which would turn on implicit_clone for the current script (current >portion of code.)
A few notes: First, either way we don't need a new function - if we wanted to do it, we could simply prevent users from using it except for with ini_set() (tag it with ZEND_INI_USER only). Second, I think that the advantages and disadvantages here are about the same, without there being a perfect solution. If we don't allow people to set it globally, upgrading becomes much more annoying. On the other hand, if we do - new PHP 5 scripts will have to explicitly turn this compatibility mode off if they want to be absolutely certain that it's not there. My personal opinion leans towards allowing people to set it on a global scale, so that it makes upgrading much simpler - I wouldn't want to force people to start hacking all of their files before they can even test whether PHP 5 works for them. Maybe we can go for a compromise - enable it with ZEND_INI_PERDIR and ZEND_INI_UUSE. That way it will be possible to use it with httpd.conf / .htaccess / ini_set(), but not with php.ini, so people will at least have to make a slightly more informed decision to enable it. Just a suggestion, I'm not sure I like it myself :) Zeev

Rasmus Lerdorf

23 years ago
On Mon, 23 Jun 2003, Zeev Suraski wrote:
> Maybe we can go for a compromise - enable it with ZEND_INI_PERDIR and > ZEND_INI_UUSE. That way it will be possible to use it with httpd.conf / > .htaccess / ini_set(), but not with php.ini, so people will at least have > to make a slightly more informed decision to enable it. Just a suggestion, > I'm not sure I like it myself :)
That'd be a bit weird and people would ask us why it doesn't work in the php.ini file. I think you can get close to the same effect by simply not listing it in the default php.ini file so they would actually have to read about it in the docs along with its implications before they knew how to set it. -Rasmus

Zeev Suraski

23 years ago
At 18:39 23/06/2003, Rasmus Lerdorf wrote:
>On Mon, 23 Jun 2003, Zeev Suraski wrote: > > Maybe we can go for a compromise - enable it with ZEND_INI_PERDIR and > > ZEND_INI_UUSE. That way it will be possible to use it with httpd.conf / > > .htaccess / ini_set(), but not with php.ini, so people will at least have > > to make a slightly more informed decision to enable it. Just a suggestion, > > I'm not sure I like it myself :) > >That'd be a bit weird and people would ask us why it doesn't work in the >php.ini file.
I agree.
>I think you can get close to the same effect by simply not >listing it in the default php.ini file so they would actually have to read >about it in the docs along with its implications before they knew how to >set it.
Not sure, I'm not even sure whether it should be missing from php.ini or just have a BIG warning about it, saying it should not be used for shared hosts... Zeev

Sterling Hughes

23 years ago
On Mon, 2003-06-23 at 11:59, Zeev Suraski wrote:
> At 18:39 23/06/2003, Rasmus Lerdorf wrote: > >On Mon, 23 Jun 2003, Zeev Suraski wrote: > > > Maybe we can go for a compromise - enable it with ZEND_INI_PERDIR and > > > ZEND_INI_UUSE. That way it will be possible to use it with httpd.conf / > > > .htaccess / ini_set(), but not with php.ini, so people will at least have > > > to make a slightly more informed decision to enable it. Just a suggestion, > > > I'm not sure I like it myself :) > > > >That'd be a bit weird and people would ask us why it doesn't work in the > >php.ini file. > > I agree. > > >I think you can get close to the same effect by simply not > >listing it in the default php.ini file so they would actually have to read > >about it in the docs along with its implications before they knew how to > >set it. > > Not sure, I'm not even sure whether it should be missing from php.ini or > just have a BIG warning about it, saying it should not be used for shared > hosts... >
I think it should just be a function then. Most PHP projects have one file that every other file includes. Why can't they just add that function call to this file? If you put this option in a place that can be globally settable, you automatically require, warning or not, that people put a :: ini_set('ze2.implicit_clone', false); at the top of their scripts. I think we have to make it unsettable in php.ini. I don't care what we do outside of that. -Sterling PS: Remember, not all shared hosts allow you to set options in a .htaccess file.
> Zeev
-- "I can't give you a brain, so I'll give you a diploma" - The Great Oz, The Wizard of Oz

Derick Rethans

23 years ago
On Mon, 23 Jun 2003, Zeev Suraski wrote:
> At 18:39 23/06/2003, Rasmus Lerdorf wrote: > >On Mon, 23 Jun 2003, Zeev Suraski wrote: > > > Maybe we can go for a compromise - enable it with ZEND_INI_PERDIR and > > > ZEND_INI_UUSE. That way it will be possible to use it with httpd.conf / > > > .htaccess / ini_set(), but not with php.ini, so people will at least have > > > to make a slightly more informed decision to enable it. Just a suggestion, > > > I'm not sure I like it myself :) > > > >That'd be a bit weird and people would ask us why it doesn't work in the > >php.ini file. > > I agree.
I think I rather have people bitching about that than bitch about the wrongly set setting. The latter creates bugreports, the first only stupid questions.
> >I think you can get close to the same effect by simply not > >listing it in the default php.ini file so they would actually have to read > >about it in the docs along with its implications before they knew how to > >set it. > > Not sure, I'm not even sure whether it should be missing from php.ini or > just have a BIG warning about it, saying it should not be used for shared > hosts...
That's basically inviting them to turn it on :) Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Zeev Suraski

23 years ago
At 19:49 23/06/2003, Derick Rethans wrote:
>I think I rather have people bitching about that than bitch about the >wrongly set setting. The latter creates bugreports, the first only >stupid questions.
I don't consider people bumping into problems upgrading asking questions as being stupid... Most people are not familiar with the ability to put INI settings in the httpd.conf/.htaccess file, at least much fewer than those who are familiar with php.ini...
> > Not sure, I'm not even sure whether it should be missing from php.ini or > > just have a BIG warning about it, saying it should not be used for shared > > hosts... > >That's basically inviting them to turn it on :)
I don't think so. I *would* in fact call the people who turn it on without taking this warning into account as stupid. If shared hosts are our main concern, how about we fail to start if both safe_mode and implicit_clone are enabled, spitting out an error that tells them that they shouldn't be using it in shared environments? Again, just an idea :) Zeev