On Mon, 30 Aug 2004, Andi Gutmans wrote:
Adam,
That link is in the History section of the Zend Engine II section. We left
it and our original RFC there so that people can take a look but PHP 5 has
changed very much since then.
Perhaps it's a good idea to add a BIG disclaimer on that same
Dear all,
I would like to request that set_exception_handler's behaviour be
changed. IMHO it should not die after handling an exception.
I feel that most users will expect this behaviour to be synonymous (i.e.
both should echo foo):
try {
throw someException;
}
catch (someException $e) { }
The bugs I saw were just the result of a quick search for multibyte, or
more --enable-zend-multibyte:
http://bugs.php.net/search.php?search_for=--enable-zend-
multibyteboolean=0limit=10order_by=direction=ASCcmd=displaystatus=Openphp_os=phpver=assign=author_email=bug_age=0
A few relevant ones
Hello,
I walked through the bugs you mentioned, however I cannot find any
bugs really related to the option (apparently all of the bugs have
nothing to do with the option).
so, actually I'm still not sure why you think the option causes
bugs. or, just because you searched the bugs with the
On Tue, 31 Aug 2004, Masaki Fujimoto wrote:
http://bugs.php.net/bug.php?id=29518
how do you think about this? it's worth fixing? or you think this
is just a bogus one?
It's not very easy to fix I think, and where is it documented that the
ini files that this function parses can be in any
On Mon, Aug 30, 2004 at 04:40:13PM -0700, Andi Gutmans wrote:
At 11:17 PM 8/30/2004 +0100, Joe Orton wrote:
On Mon, Aug 30, 2004 at 02:20:42PM -0700, Andi Gutmans wrote:
I know it's undefined but why is defining it to LONG_MAX/LONG_MIN any
better? It's not the kind of behavior which I think
Also, the bug27354 test needs to be updated since it relies on
particular behaviour of integers greater than LONG_MAX on 32-bit
platforms; since it looks like it is only really checking for
not-a-division-by-zero-trap, this seems OK:
--- php-4.3.8/tests/lang/bug27354.phpt.dval2lval
+++
On Tue, 31 Aug 2004, Joe Orton wrote:
Also, the bug27354 test needs to be updated since it relies on
particular behaviour of integers greater than LONG_MAX on 32-bit
platforms; since it looks like it is only really checking for
not-a-division-by-zero-trap, this seems OK:
Yup, please commit
On Tue, Aug 31, 2004 at 11:47:06AM +0200, Derick Rethans wrote:
On Tue, 31 Aug 2004, Joe Orton wrote:
Also, the bug27354 test needs to be updated since it relies on
particular behaviour of integers greater than LONG_MAX on 32-bit
platforms; since it looks like it is only really checking
On Tue, 31 Aug 2004, Joe Orton wrote:
On Tue, Aug 31, 2004 at 11:47:06AM +0200, Derick Rethans wrote:
On Tue, 31 Aug 2004, Joe Orton wrote:
Also, the bug27354 test needs to be updated since it relies on
particular behaviour of integers greater than LONG_MAX on 32-bit
platforms;
On Tue, Aug 31, 2004 at 12:02:31PM +0200, Derick Rethans wrote:
On Tue, 31 Aug 2004, Joe Orton wrote:
On Tue, Aug 31, 2004 at 11:47:06AM +0200, Derick Rethans wrote:
On Tue, 31 Aug 2004, Joe Orton wrote:
Also, the bug27354 test needs to be updated since it relies on
particular
Hi
The following came up in a bug report (http://bugs.php.net/?id=29911 ,
but it doesn't matter, as he tried something which doesn't work either way)
?php
class foo {};
$foo1 = new foo();
$foo2 = new foo();
var_dump($foo1 == $foo2);
?
prints now true, but according to Derick and
On Tue, Aug 17, 2004 at 12:54:55PM -0700, Andi Gutmans wrote:
Hi agree with Joe on this one. I think it would be beneficial to include
this patch *even* if it means that we might have to update it from time to
time. I'm sure Joe will lend a helping hand to do so.
So, am I OK to commit this
On Tuesday 31 August 2004 14:39, Joe Orton wrote:
On Tue, Aug 17, 2004 at 12:54:55PM -0700, Andi Gutmans wrote:
Hi agree with Joe on this one. I think it would be beneficial to include
this patch *even* if it means that we might have to update it from time
to time. I'm sure Joe will lend a
The final release candidate of PHP 4.3.9 is now available for testing. Hf no
new problems are uncovered, this release will be re-released as 4.3.9 at the
end of the week. If you have any patches (4.X tree) for non-critical problems
please hold them off either until we decide that another RC is
Yeah good idea. I'll try and see what I can do.
Andi
At 08:14 AM 8/31/2004 +0200, Derick Rethans wrote:
On Mon, 30 Aug 2004, Andi Gutmans wrote:
Adam,
That link is in the History section of the Zend Engine II section. We left
it and our original RFC there so that people can take a look but PHP
There's nothing stopping someone from writing their own classes for
dispatching and handling events and implementing callbacks today...
Are you suggesting something built into PHP like the Java system event
queue that people can define their own dispatchers and handlers for?
The QT example below
Hi,
To speed up a homebuild PHP framework I would like to have a new
function that expands a string with the PHP variables in it, just like
how variable parsing is done for a double-quotes string.
string VariableParsingString ( string string )
Currently I do it with the next eval statement.
Actually, php-gtk has it's own connect/emit mechanism, what is
problematic, is that a number of projects (both pear packages and
others) utilize a callback/event model, and the only 2 ways to implement
it are as a visitor type class, or recode the same simple method in a
number of places.
In
http://nl.php.net/parse_str
On Tue, 31 Aug 2004, Herbert Groot Jebbink wrote:
Hi,
To speed up a homebuild PHP framework I would like to have a new
function that expands a string with the PHP variables in it, just like
how variable parsing is done for a double-quotes string.
string
Hello,
We sent you an email a while ago, because you now qualify for a new mortgage.
You could get $300,000 for as little as $700 a month!
Bad credit is no problem, you can pull cash out or refinance.
Please click on this link for free consultation by a mortgage broker:
http://www.fnytqua.com/
Hi Davey,
You should use try/catch in order to catch exceptions.
set_exception_handler() is only meant for you to be able to handle uncaught
exception before PHP dies (i.e.allow you to output an error message page).
I think your idea goes very much against what exceptions stand for which is
Hi Joe,
It does look as if you're right. I don't quite understand why the standard
was written in such a way and not in a way which only makes the value
itself undefined.
I think we can apply the patch. Does anyone have a problem with setting
arbitrary numbers such as LONG_MAX/LONG_MIN for an
Hi Christian,
This was a backwards compatibility issue and therefore, we made sure that
PHP 5 behaves the same way as PHP 4. So if both objects are PHP objects it
will do a PHP 4 object comparison.
If you use === (is identical) then we will only compare handles unless in
Amen :)
At 09:03 PM 8/31/2004 +0200, Marcus Boerger wrote:
Hello Davey,
Tuesday, August 31, 2004, 8:41:45 AM, you wrote:
Dear all,
I would like to request that set_exception_handler's behaviour be
changed. IMHO it should not die after handling an exception.
An exception means that the current
25 matches
Mail list logo
