On Feb 6, 2008 2:13 AM, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
Daniel Brown wrote:
On Feb 5, 2008 3:26 PM, Daniel Brown [EMAIL PROTECTED] wrote:
On Feb 5, 2008 3:23 PM, Pierre Joye [EMAIL PROTECTED] wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
On Tue, 5 Feb 2008, Richard Lynch wrote:
On Sun, February 3, 2008 7:51 pm, Stanislav Malyshev wrote:
Like I mentioned before (I think), it should not return an empty
string of course because programmatically it's not possible to
check for this. As most of our functions return false in
On Feb 6, 2008 9:31 AM, Derick Rethans [EMAIL PROTECTED] wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same way as the
other type hints that we laready have.
Same here.
--
Pierre
http://blog.thepimp.net |
On Tue, 5 Feb 2008, Mike Willbanks wrote:
I know they've been marked deprecated and all, but, really, what's
the cost/penalty to having a couple functions around for legacy apps?
Then we will continue to be at the same old issue of they exist, people will
continue to use them and never
You forget that for most shared
hosters they just install PHP so that they can say they support it, but
actually don't give a ratsass about what is actually supported.
I totally agree, most hosts just install what comes as default with a
distribution, they don't care or even bother with PECL
On Wed, 6 Feb 2008, Steph Fox wrote:
As with so many topics on this list, I have no authority to influence
the outcome. I personally think they've all got rules to instantly
delete my email (but that's cause I'm paranoid).
That's rubbish Richard - in some ways you're the most important
On Tue, 5 Feb 2008, Pierre Joye wrote:
There is not really a need to discuss the removal again, that's why I
ask for a simple vote:
+1: remove them (as it is now in HEAD)
-1: Restore them and always return FALSE (not 0)
0: I don't care, do what you wish, I never use them anyway
I don't
Hi both,
I totally agree, most hosts just install what comes as default with a
distribution, they don't care or even bother with PECL in 99% of cases in
my
experience.
Well - that can't be entirely true or there'd be next to no MySQL support
out there!
I just think we make it needlessly
Well - that can't be entirely true or there'd be next to no MySQL support
out there!
I knew that would come back and bite me on the ass as soon as I posted! :-)
MySQL support is one of the noteable exceptions as its considered core to
web-hosts (In their eyes PHP and MySQL are one) other
On Feb 6, 2008 11:12 AM, Marco [EMAIL PROTECTED] wrote:
Well - that can't be entirely true or there'd be next to no MySQL support
out there!
I knew that would come back and bite me on the ass as soon as I posted! :-)
MySQL support is one of the noteable exceptions as its considered core
Hi Pierre,
The main reason (from my experiences) for the ISP is lazynes. They
don't care about what the users may need or not but simply run
configure, make make install, or use the xyz distribtutions default
package to run common applications like phpmyadmin or wordpress.
That's a heck of an
Hi Marco,
I think one of the reasons hosts don't like / use PECL is trust, they
trust
what comes with the PHP core packages and consider anything else a
security
risk. Maybe a combination of better distribution, package details,
stability
(beta / alpha) etc and maybe something that deals
On Feb 6, 2008 11:32 AM, Steph Fox [EMAIL PROTECTED] wrote:
Hi Pierre,
The main reason (from my experiences) for the ISP is lazynes. They
don't care about what the users may need or not but simply run
configure, make make install, or use the xyz distribtutions default
package to run
Hi Scott,
I'm fine with your patch.
Please commit it, or let me know if you like me to commit it.
Thanks. Dmitry.
Scott MacVicar wrote:
Hi,
While doing some threaded work I noticed that tsrm_mutex_lock and
tsrm_mutex_unlock return different values for Windows and Linux (using
pthread).
On 06/02/2008, Steph Fox [EMAIL PROTECTED] wrote:
By the way:
http://www.nexen.net/articles/dossier/18038-base_configuration_for_php_5.2.5.php
Thanks for that, Pierre. But I think those stats add to the argument for
making PECL easier to deal with, rather than diminishing it.
- Steph
By the way:
http://www.nexen.net/articles/dossier/18038-base_configuration_for_php_5.2.5.php
Thanks for that, Pierre. But I think those stats add to the argument for
making PECL easier to deal with, rather than diminishing it.
- Steph
--
Pierre
http://blog.thepimp.net |
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same way as the
other type hints that we laready have.
I also agree with this too.
Add the common types first and then if there is a good reason, add special
ones but
-1
Pierre Joye schreef:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other
-1
On Feb 5, 2008 10:23 PM, Pierre Joye [EMAIL PROTECTED] wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done
+1 - remove the functions
To make a script compatible one has to add
function get_magic_quotes_gpc(){return 0;}
in one of his library files.
I think the current change is somewhat similar to PHP_INI_ALL in PHP -
PHP_INI_PERDIR for magic_quotes_gpc made in 4.2.3. It also could lead to
breakage
Hello Pierre,
internal c-level code is written in a way that it expects $this to be
available and will crash if it is not for the most. Thus we prevent calling
internal dynamic functions as static ones unless they are flagged as such.
Tuesday, February 5, 2008, 11:17:11 PM, you wrote:
On Feb
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Steph Fox wrote:
As with so many topics on this list, I have no authority to influence
the outcome. I personally think they've all got rules to instantly
delete my email (but that's cause I'm paranoid).
Hi Dmitry,
I don't have karma for TSRM only php-src.
Scott
Dmitry Stogov wrote:
Hi Scott,
I'm fine with your patch.
Please commit it, or let me know if you like me to commit it.
Thanks. Dmitry.
Scott MacVicar wrote:
Hi,
While doing some threaded work I noticed that tsrm_mutex_lock and
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same way as the
other type hints that we laready have.
True,
To me it does not make sense to have a scalar type hint. For the
simple reason it's inconsistent with PHP, and it adds no value other
then the fact you then know the value is not on array (or maybe not a
resource?). It's also inconsistent with PHP, array type hinting, is
complemented by array
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same
On Wed, 2008-02-06 at 06:30 -0700, Chris Stockton wrote:
To me it does not make sense to have a scalar type hint. For the
simple reason it's inconsistent with PHP, and it adds no value other
then the fact you then know the value is not on array (or maybe not a
Ok. Well the array type hint
HI Sam,
On Feb 6, 2008 2:33 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the
Ok. Well the array type hint ensures that it is an array. This just does
the opposite then, I don't see a problem with that. I like to be able to
protected my code from having arrays/objects accidentally inserted into
databases or outputted.
I completely understand you want to create (easier)
Wow, you guys sure are a bit harsh
Here's the problem - there's a group of people who really want true (I
might say javaish) type-hints for scalar values - int, bool, string,
float, and won't settle for anything less.
There's a group who thinks type hints are stupid because of the way php
On Wed, 2008-02-06 at 15:31 +0100, Pierre Joye wrote:
HI Sam,
On Feb 6, 2008 2:33 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
Hi Sam,
On Feb 6, 2008 4:08 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 15:31 +0100, Pierre Joye wrote:
HI Sam,
On Feb 6, 2008 2:33 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow
On Wed, 2008-02-06 at 10:09 -0500, Elizabeth M Smith wrote:
Wow, you guys sure are a bit harsh
Here's the problem - there's a group of people who really want true (I
might say javaish) type-hints for scalar values - int, bool, string,
float, and won't settle for anything less.
Hi All,
Just a suggestion. Maybe make your case analyzing a set of
representative php applications for calls to the various is*() methods
(maybe even factoring in assert()). This could help in showing how
often people are currently forced to write out type checks.
My humble guess:
On 5 Feb 2008, at 20:23, Pierre Joye wrote:
There is not really a need to discuss the removal again, that's why I
ask for a simple vote:
+1
--
Geoffrey Sneddon
http://gsnedders.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Feb 6, 2008 5:13 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Hi All,
Just a suggestion. Maybe make your case analyzing a set of
representative php applications for calls to the various is*() methods
(maybe even factoring in assert()). This could help in showing how
often people are
Really, it's not the most accurate test, to make it more accurate you
would only check parameter variables but I wanted something fast.
These are the calls to the is_* family from a major library. All calls
are within a Class { }. I think this shows several things, a couple I
would like to mention
Sam Barrow schrieb:
If anyone has any objections to a scalar type hint please raise a
valid point.
Chris Stockton schrieb:
This library would probably have ~300(String) + ~110(Int)
~40(Resource) ~30(Bool) ~10(Float) = 500 less function calls, and much
cleaner code if there was type hinting.
On Wed, Feb 06, 2008 at 06:47:23PM +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
If anyone has any objections to a scalar type hint please raise a
valid point.
Chris Stockton schrieb:
This library would probably have ~300(String) + ~110(Int)
~40(Resource) ~30(Bool) ~10(Float) = 500
This library would probably have ~300(String) + ~110(Int)
~40(Resource) ~30(Bool) ~10(Float) = 500 less function calls, and much
cleaner code if there was type hinting.
You forgot the code that you'd have to write to deal with the situation
that typehinted function fails.
I understand a lot
On Feb 6, 2008 7:13 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
with. Bottom line all stubbornness should be put aside and look to see
if it would improve the language use and appeal to a large user base,
No, it won't improve.
for you.
Cheers,
--
Pierre
http://blog.thepimp.net |
Markus Fischer wrote:
+1
I didn't realized it until I read Rasmus' mail. In this case, -1 to not break
BC.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Pierre Joye wrote:
Hi,
+1: remove them (as it is now in HEAD)
-1: Restore them and always return FALSE (not 0)
0: I don't care, do what you wish, I never use them anyway
-1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2008/2/6, Derick Rethans [EMAIL PROTECTED]:
I don't care that much, but I think it would matter if the functions
just are there and return false (so -1).
for set_magic_quotes_runtime(), if true is passed, it should still
throw a fatal error, if false is passed it should not (or actually 1
On Feb 6, 2008 9:20 PM, Cristian Rodriguez [EMAIL PROTECTED] wrote:
2008/2/6, Derick Rethans [EMAIL PROTECTED]:
I don't care that much, but I think it would matter if the functions
just are there and return false (so -1).
for set_magic_quotes_runtime(), if true is passed, it should still
-1
Suggestion to enhance the suggestion: return false + emit E_STRICT
message (but I am also fine with pure return false if people don't like
this suggestion).
Andi
-Original Message-
From: Pierre Joye [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 05, 2008 12:23 PM
To: PHP
0 for me
-1 for all the people who'll bug the mailing lists askign where they've gone
suggest: E_NOTICE or E_STRICT telling the magic_quotes_runtime has gone
BUT in the next php 5.2.X release so peeps get used to it!
Pierre Joye wrote:
Hi,
It seems that there is voices in favor of keeping
Hi Andi,
On Feb 7, 2008 12:56 AM, Andi Gutmans [EMAIL PROTECTED] wrote:
-1
Suggestion to enhance the suggestion: return false + emit E_STRICT
message (but I am also fine with pure return false if people don't like
this suggestion).
Sounds reasonable too. It would be nice to add a deprecate
On Wed, 2008-02-06 at 16:39 -0800, Stanislav Malyshev wrote:
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
requests. However, in most cases we do
I'm going to rock the boat again I guess...
Suggestion to enhance the suggestion: return false + emit E_STRICT
message (but I am also fine with pure return false if people don't like
this suggestion).
Sounds reasonable too. It would be nice to add a deprecate notice in
5.3.x as well.
Sam Barrow wrote:
On Wed, 2008-02-06 at 16:39 -0800, Stanislav Malyshev wrote:
[snip]
The proposal(s):
1. One way to fix it is to create a new .ini request_order that would
control just _REQUEST.
2. Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e.
Pierre Joye wrote:
-1: Restore them and always return FALSE (not 0)
-1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev wrote:
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
requests. However, in most cases we do not want GET/POST variables to
On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote:
Stanislav Malyshev wrote:
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
54 matches
Mail list logo
