On 2010-05-21 20:12:18 +0200, Stas Malyshev said:
Hi!
I agree that enum make more sense when it's a type but I disagree with
the fact that it make code less understandable. The goal of this patch
is to make it easy to create a list of constants when the value is not
necessarily important (For
Hi guys,
On the nginx mailing list, there is an interesting conversation about
the usage of php through fastcgi with nginx which can cause a security
hole:
http://forum.nginx.org/read.php?2,88845
I don't really know the origin of the fix_pathinfo ini variable. So I
don't know if it's really a bug
Hi!
I agree that enum make more sense when it's a type but I disagree with
the fact that it make code less understandable. The goal of this patch
is to make it easy to create a list of constants when the value is not
necessarily important (For example when you create a lexer you don't
mind if th
On Thu, May 20, 2010 at 11:28, Frederic Hardy
wrote:
> 1) What is exactly zend multibyte support ?
Not something you should use without knowing exactly what it is
> 2) Is it normal that phar support is broken when i use it ?
No. Definitely not. Please file a bug report about it, preferably with
I agree that enum make more sense when it's a type but I disagree with
the fact that it make code less understandable. The goal of this patch
is to make it easy to create a list of constants when the value is not
necessarily important (For example when you create a lexer you don't
mind if the integ
Hi!
Following Richard's e-mail I created a patch and a RFC (
http://wiki.php.net/rfc/enum ) to introduce the enum language
structure.
I'm not sure what exactly enums would add except for inability to figure
out what is the actual value of the constant. IMHO it just makes code
less understand
Following Richard's e-mail I created a patch and a RFC (
http://wiki.php.net/rfc/enum ) to introduce the enum language
structure.
Two patches are available on to create an enumeration as Richard's suggested
class foo {
const enum {
CASE_1,
CASE_2,
CASE_3,
CASE_4
};
}
And one other without
+1
Brian.
http://brian.moonspot.net/
On 5/21/10 10:38 AM, Ralph Schindler wrote:
Hey all,
Attached is a patch to remove the warning from parse_url() in situations
where parse_url() cannot actually parse the url. The bug report also
claims there should be a new feature for understand
Really attached this time.
Attached is a patch to remove the warning from parse_url() in situations
diff --git a/ext/standard/tests/url/parse_url_basic_001.phpt
b/ext/standard/tests/url/parse_url_basic_001.phpt
index 3d50689..7b9d513 100644
--- a/ext/standard/tests/url/parse_url_basic_001.phpt
Hey all,
Attached is a patch to remove the warning from parse_url() in situations
where parse_url() cannot actually parse the url. The bug report also
claims there should be a new feature for understanding "why" a parsed
url failed. That code currently does not exist, and the current warnin
On 05/21/2010 10:46 AM, Michael Wallner wrote:
See the test included in the patch respectively bug #45706 [2]
what this exactly means.
[2]http://bugs.php.net/45706
Sorry, wrong bug referenced. The request I actually meant is 36424:
http://bugs.php.net/36424
Mike
--
PHP Internals - PHP Runt
Hi,
I prepared a patch [1] which enables serialize() to keep track of
object/variable references through its var_hash throughout
recursive calls to serialize().
See the test included in the patch respectively bug #45706 [2]
what this exactly means.
It also has the side affect that the hack [3]
12 matches
Mail list logo
