Fair enough Wez :)
On Thu, 2005-08-25 at 20:34 -0400, Wez Furlong wrote:
In some environments you *need* to run a zts enabled PHP.
People that run in those environments can heed the warnings about
potential stability issues, evaluate them, and decide whether it makes
sense for their
At 03:34 26/08/2005, Wez Furlong wrote:
In some environments you *need* to run a zts enabled PHP.
People that run in those environments can heed the warnings about
potential stability issues, evaluate them, and decide whether it makes
sense for their application.
I don't see any compelling need
On Thu, 25 Aug 2005, Ilia Alshanetsky wrote:
I think there is a good reason for this patch making its way into PHP
5.1 and 5.0, any chance relevant RMs could be convinced to allow it? :-)
Patch for 5.1 is here:
http://files.derickrethans.nl/patches/e_recoverable_error-php-5.1-20050826.diff.txt
On Wed, 24 Aug 2005, Zeev Suraski wrote:
At 09:26 24/08/2005, Derick Rethans wrote:
On Tue, 23 Aug 2005, Andi Gutmans wrote:
I didn't quite understand. Users would be able to handle E_FATAL
errors? How
would exceptions from those user handlers propagate the C extensions?
No, they
At 10:17 25/08/2005, Marcus Boerger wrote:
Hello Andi,
wow, now that makes me wonder if you perhaps also know a reason for?
I mean in theory it should be faster shouldn't it? Or is the problem
that we far to often use TRSMLS_FETCH() with all its disadvantages?
Whenever we touch a shared
Derick Rethans wrote:
I implemented that (except I dropped the _ERROR part for
E_RECOVERABLE_ERROR as I found it too long). The patch is here:
http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt
Any comments?
+1 overall. As much as I like to keep name short, I think the full
On Thu, 25 Aug 2005, Zeev Suraski wrote:
At 15:44 25/08/2005, Ilia Alshanetsky wrote:
Derick Rethans wrote:
I implemented that (except I dropped the _ERROR part for
E_RECOVERABLE_ERROR as I found it too long). The patch is here:
On Thu, 25 Aug 2005, Derick Rethans wrote:
On Thu, 25 Aug 2005, Zeev Suraski wrote:
At 15:44 25/08/2005, Ilia Alshanetsky wrote:
Derick Rethans wrote:
I implemented that (except I dropped the _ERROR part for
E_RECOVERABLE_ERROR as I found it too long). The patch is here:
Ilia Alshanetsky wrote:
I think there is a good reason for this patch making its way into PHP
5.1 and 5.0, any chance relevant RMs could be convinced to allow it? :-)
Not sure about 5.0, but it should go into (yet unreleased) 5.1 IMHO.
Edin
--
PHP Internals - PHP Runtime Development Mailing
Hello Zeev,
Thursday, August 25, 2005, 2:55:43 PM, you wrote:
At 15:44 25/08/2005, Ilia Alshanetsky wrote:
Derick Rethans wrote:
I implemented that (except I dropped the _ERROR part for
E_RECOVERABLE_ERROR as I found it too long). The patch is here:
I don't buy into the argument that we shouldn't start even trying to
solve the thread safety issues in PHP because of some arbitrary we
can't tell or it's faster not to do it sort of argument. Threads
aren't exactly an archaic or edge technology, and it's just stubborn of
us not to support them.
I generally disagree.
There are almost no advantages to multithreaded PHP. There are
disadvantages (the reduced stability is inherent; no matter how good PHP
gets, multi-process deployments are by definition more
robust). Performance is slightly degraded too, so why bother?
And yes,
I don't think anyone was arguing that we should fix TS issues. We've
been doing that for ages (since the early days of PHP 4).
The question is wether there is much value in marking extensions as
thread-safe.
At 12:35 PM 8/25/2005, John Coggeshall wrote:
I don't buy into the argument that we
On Thu, 2005-08-25 at 23:09 +0300, Zeev Suraski wrote:
There are almost no advantages to multithreaded PHP. There are
disadvantages (the reduced stability is inherent; no matter how good PHP
gets, multi-process deployments are by definition more
robust). Performance is slightly degraded
As Zeev stated it's additional thread-storage fetching and passing an
extra parameter. However, it's a marginal difference so I wouldn't
base my architectural decision on that. It was only regarding
performance decision. I wouldn't base my architecture decision solely
based on performance but
In some environments you *need* to run a zts enabled PHP.
People that run in those environments can heed the warnings about
potential stability issues, evaluate them, and decide whether it makes
sense for their application.
I don't see any compelling need to rip out a feature that is essential
On Tue, 23 Aug 2005, Andi Gutmans wrote:
I didn't quite understand. Users would be able to handle E_FATAL errors? How
would exceptions from those user handlers propagate the C extensions?
No, they would only be able to catch E_ERROR, E_FATAL is the current
E_ERROR and can NOT be caught by the
At 09:26 24/08/2005, Derick Rethans wrote:
On Tue, 23 Aug 2005, Andi Gutmans wrote:
I didn't quite understand. Users would be able to handle E_FATAL
errors? How
would exceptions from those user handlers propagate the C extensions?
No, they would only be able to catch E_ERROR, E_FATAL is
On Wed, 24 Aug 2005, Zeev Suraski wrote:
At 09:26 24/08/2005, Derick Rethans wrote:
On Tue, 23 Aug 2005, Andi Gutmans wrote:
I didn't quite understand. Users would be able to handle E_FATAL
errors? How would exceptions from those user handlers propagate
the C extensions?
No,
Replacing the meaning of E_ERROR is elegant, but it does create a
problem of cross-version compatibility of extensions (at the source
code level). If you want to raise an error that terminates execution,
you'll have to do it in two different ways - that's quite annoying.
While I think
At 17:21 24/08/2005, Rasmus Lerdorf wrote:
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when they're
updated...?
That's going to be tough. They will definitely lose binary
compatibility
Hi Rasmus,
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when they're
updated...?
That's going to be tough. They will definitely lose binary
compatibility because all sorts of internal
Ouf - you're effectively saying that Unicode support will need to be
enabled
via INI directives on a per-extension basis? Or that there will need to
be
two versions of every PHP extension?
Not at all. But it would be nice if the extension did something
intelligent when passed an
At 17:37 24/08/2005, Rasmus Lerdorf wrote:
Steph wrote:
Hi Rasmus,
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when they're
updated...?
That's going to be tough. They will definitely lose
Zeev Suraski wrote:
At 17:37 24/08/2005, Rasmus Lerdorf wrote:
Steph wrote:
Hi Rasmus,
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when
they're
updated...?
That's going to be
On Wed, 24 Aug 2005, Zeev Suraski wrote:
At 17:21 24/08/2005, Rasmus Lerdorf wrote:
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when they're
updated...?
That's going to be tough.
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when they're
updated...?
That's going to be tough. They will definitely lose binary
compatibility because all sorts of internal structures are
At 17:46 24/08/2005, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
At 17:37 24/08/2005, Rasmus Lerdorf wrote:
Steph wrote:
Hi Rasmus,
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when
Zeev Suraski wrote:
Why? A great deal of users will be running with unicode semantics
turned off, and I don't see a good reason to break source compatibility
for them. For example, if Foo Inc. wrote a module for PHP 4, and they
want to migrate to PHP 6 - it should be a simple recompile.
On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote:
Maybe we can give extensions a way to indicate that they're Unicode
compatible, and assume they're not if they don't. Non-compatible
extensions will not be loaded and produce an error.
Not to hijack the topic, but if we are going to do
At 18:05 24/08/2005, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
Why? A great deal of users will be running with unicode semantics
turned off, and I don't see a good reason to break source compatibility
for them. For example, if Foo Inc. wrote a module for PHP 4, and they
want to migrate to
Hello John,
Wednesday, August 24, 2005, 5:22:07 PM, you wrote:
On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote:
Maybe we can give extensions a way to indicate that they're Unicode
compatible, and assume they're not if they don't. Non-compatible
extensions will not be loaded and
Hello Zeev,
Wednesday, August 24, 2005, 4:41:25 PM, you wrote:
At 17:37 24/08/2005, Rasmus Lerdorf wrote:
Steph wrote:
Hi Rasmus,
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when
At 08:05 AM 8/24/2005, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
Why? A great deal of users will be running with unicode semantics
turned off, and I don't see a good reason to break source compatibility
for them. For example, if Foo Inc. wrote a module for PHP 4, and they
want to migrate
Marcus,
You will most likely find that the faster Apache way with
thread-safe PHP is slower than the slower Apache way with
non-thread-safe PHP. And even FastCGI will be faster :)
Andi
At 12:25 PM 8/24/2005, Marcus Boerger wrote:
Hello John,
Wednesday, August 24, 2005, 5:22:07 PM, you
On Mon, 22 Aug 2005, George Schlossnagle wrote:
E_FATAL
Leaving current errors as E_ERROR (since most are recoverable, imho)
I have a patch for this ready. In most of the engine I converted all
E_ERRORs to E_FATALs (except the type hints), and in most of the
extensions I kept the E_ERRORs
Hi Derick,
I didn't quite understand. Users would be able to handle E_FATAL
errors? How would exceptions from those user handlers propagate the C
extensions?
Andi
At 05:15 AM 8/23/2005, Derick Rethans wrote:
On Mon, 22 Aug 2005, George Schlossnagle wrote:
E_FATAL
Leaving current errors
Generally speaking, many users want to be able to catch every error
possible. If there is an error condition that happens, they want to be
able to catch it.
If it's not possible to catch it in script, perhaps an extension or some
other strategy needs to be documented for certain error
On Thu, 11 Aug 2005, Derick Rethans wrote:
On Thu, 11 Aug 2005, Zeev Suraski wrote:
You mean it shouldn't be able to stop the application, or that the
application
should be able to prevent this error from stopping it? If it's the latter,
then it would be possible. If it's the
At 12:53 22/08/2005, Derick Rethans wrote:
On Thu, 11 Aug 2005, Derick Rethans wrote:
On Thu, 11 Aug 2005, Zeev Suraski wrote:
You mean it shouldn't be able to stop the application, or that the
application
should be able to prevent this error from stopping it? If it's the
latter,
On Mon, 22 Aug 2005, Zeev Suraski wrote:
It seems most are for
another type of error that are fatal if not handled in the user error
handler. There is just one thing... how do we signal it back from the
handler? Currently there is no defined return value for the user defined
error handler. I
At 14:34 22/08/2005, Derick Rethans wrote:
On Mon, 22 Aug 2005, Zeev Suraski wrote:
It seems most are for
another type of error that are fatal if not handled in the user error
handler. There is just one thing... how do we signal it back from the
handler? Currently there is no defined return
On Mon, 22 Aug 2005, Andrei Zmievski wrote:
I thought I made that patch a while ago?
zend.c:
if (retval) {
if (Z_TYPE_P(retval) == IS_BOOL Z_LVAL_P(retval) == 0)
{
zend_error_cb(type, error_filename, error_lineno,
format, args);
Hello Zeev,
Monday, August 22, 2005, 1:38:54 PM, you wrote:
At 14:34 22/08/2005, Derick Rethans wrote:
On Mon, 22 Aug 2005, Zeev Suraski wrote:
It seems most are for
another type of error that are fatal if not handled in the user error
handler. There is just one thing... how do we signal
At 20:53 22/08/2005, Marcus Boerger wrote:
So in that case, the implementation in zend_error_cb() should simply call
the user error handler if it's available, or treat it as if it's E_ERROR if
there is no user error handler.
Isn't an E_ERROR by default good enough or do you want exceptions
On Aug 22, 2005, at 3:50 PM, Zeev Suraski wrote:
At 20:53 22/08/2005, Marcus Boerger wrote:
So in that case, the implementation in zend_error_cb() should
simply call
the user error handler if it's available, or treat it as if it's
E_ERROR if
there is no user error handler.
Isn't an
On Mon, 22 Aug 2005, George Schlossnagle wrote:
I'm talking about allowing type hints to be trappable by users, without
complicating them with exceptions. I'm proposing a new error level, which
behaves like E_ERROR, except it can be caught using a userland error
handler, for those cases
At 22:54 22/08/2005, George Schlossnagle wrote:
This sounds good to me. We talked about this briefly a year or so
ago, in reference to being able to convert E_ERROR errors to
exceptions in an extension.
Exactly.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Aug 22, 2005, at 4:02 PM, Derick Rethans wrote:
On Mon, 22 Aug 2005, George Schlossnagle wrote:
I'm talking about allowing type hints to be trappable by users,
without
complicating them with exceptions. I'm proposing a new error
level, which
behaves like E_ERROR, except it can be
E_CATCHY catchy enough or you?
-Andrei
On Aug 22, 2005, at 1:02 PM, Derick Rethans wrote:
On Mon, 22 Aug 2005, George Schlossnagle wrote:
I'm talking about allowing type hints to be trappable by users,
without
complicating them with exceptions. I'm proposing a new error level,
which
At 23:10 22/08/2005, George Schlossnagle wrote:
My original proposal (at least as I recall it), was to move
irrecoverable errors to something like
E_UNRECOVERABLE_ERROR
or
E_FATAL
Leaving current errors as E_ERROR (since most are recoverable, imho)
I like this idea except it would be a
Hello Zeev,
Monday, August 22, 2005, 11:26:12 PM, you wrote:
At 23:10 22/08/2005, George Schlossnagle wrote:
My original proposal (at least as I recall it), was to move
irrecoverable errors to something like
E_UNRECOVERABLE_ERROR
or
E_FATAL
Leaving current errors as E_ERROR (since most are
Hello George,
Monday, August 22, 2005, 10:10:24 PM, you wrote:
On Aug 22, 2005, at 4:02 PM, Derick Rethans wrote:
On Mon, 22 Aug 2005, George Schlossnagle wrote:
I'm talking about allowing type hints to be trappable by users,
without
complicating them with exceptions. I'm proposing a
At 02:28 11/08/2005, Tobias Schlitt wrote:
Hi Zeev Suraski!
On 08/10/05 17:30 you wrote:
I think
that throwing exceptions in all sorts of places encourages people to
write 'exception-oriented' apps, which is very messy.
Sorry, but I consider that statement wrong. We are still talking about
On Wed, 10 Aug 2005, Zeev Suraski wrote:
Calling to a function with the wrong arguments is something that should be
dealt with when developing the application, not at runtime. I think that
throwing exceptions in all sorts of places encourages people to write
'exception-oriented' apps, which
On Thu, 11 Aug 2005, Derick Rethans wrote:
I believe we mentioned once the possibility of adding another error level,
which is fatal - but still catchable by set_error_handler(). That is a good
idea (which we should be doing either way).
That would work well. I just want the type hints
At 11:03 11/08/2005, Derick Rethans wrote:
On Thu, 11 Aug 2005, Derick Rethans wrote:
I believe we mentioned once the possibility of adding another error
level,
which is fatal - but still catchable by set_error_handler(). That is
a good
idea (which we should be doing either way).
On Thu, 11 Aug 2005, Zeev Suraski wrote:
You mean it shouldn't be able to stop the application, or that the application
should be able to prevent this error from stopping it? If it's the latter,
then it would be possible. If it's the former, then I don't quite
understand...
The latter is
Derick Rethans wrote:
On Thu, 11 Aug 2005, Derick Rethans wrote:
I believe we mentioned once the possibility of adding another error level,
which is fatal - but still catchable by set_error_handler(). That is a good
idea (which we should be doing either way).
That would work well. I just
On Thu, 11 Aug 2005, Lukas Smith wrote:
Derick Rethans wrote:
On Thu, 11 Aug 2005, Derick Rethans wrote:
I believe we mentioned once the possibility of adding another
error level, which is fatal - but still catchable by
set_error_handler(). That is a good idea (which we should
Zeev Suraski wrote:
I believe we mentioned once the possibility of adding another error
level, which is fatal - but still catchable by set_error_handler().
What actually would be the same as having a try block around your
application.
Right, which is infinitely better. It does not
I don't think that's a good idea, regardless of implementation issues.
Calling to a function with the wrong arguments is something that should be
dealt with when developing the application, not at runtime. I think that
throwing exceptions in all sorts of places encourages people to write
Hi Zeev Suraski!
On 08/10/05 17:30 you wrote:
I think
that throwing exceptions in all sorts of places encourages people to
write 'exception-oriented' apps, which is very messy.
Sorry, but I consider that statement wrong. We are still talking about
PHP and a not caught exception will result
Derick Rethans schrieb:
I prefer not to comment on that :)
I might have something to do with that, but I am not sure.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP
On Tue, 9 Aug 2005, Sebastian Bergmann wrote:
Derick Rethans schrieb:
I prefer not to comment on that :)
I might have something to do with that, but I am not sure.
You've nothing to do with that.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
Hei,
currently if you pass a wrong object's type to a typehinted parameter:
[EMAIL PROTECTED]:~$ cat /tmp/foo.php
?php
class foo {
function bar(foo $a)
{
}
}
$a = new foo;
$a-bar(new stdClass);
Derick Rethans schrieb:
Opinions?
+1
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
+1
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Monday, August 08, 2005 11:50 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] type hinting throwing a fatal error
Hei,
currently if you pass a wrong object's type to a typehinted parameter
On Mon, 8 Aug 2005, Sebastian Bergmann wrote:
Derick Rethans schrieb:
Opinions?
+1
Does that mean you want more opinions? :)
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
Does that mean you want more opinions? :)
Throw an InvalidArgumentException from SPL...
--
Ondrej Ivanic
([EMAIL PROTECTED])
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 8 Aug 2005, Ondrej Ivanič wrote:
Derick Rethans wrote:
Does that mean you want more opinions? :)
Throw an InvalidArgumentException from SPL...
Won't work, SPL can be disabled.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Derick Rethans schrieb:
Does that mean you want more opinions? :)
No, I want a (InvalidArgument?)Exception to be thrown when I type-hint
is not met.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514
Derick Rethans schrieb:
Won't work, SPL can be disabled.
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514
Derick Rethans wrote:
Hei,
currently if you pass a wrong object's type to a typehinted parameter:
[...]
Fatal error: Argument 1 must be an instance of foo in /tmp/foo.php on
line 3
As type hinting is a new OO thing, it might perhaps make some sense to
make this an exception
Derick Rethans wrote:
As type hinting is a new OO thing, it might perhaps make some sense to
make this an exception instead - as this error might also happen for
dynamic things by people who use the classes you designed. In that case
having this fatal error to stop the whole application can be
Hmm,
I was complaining about inusaability ot type hinting because of this fatal
errors but nobody seems heard me :(. One better do a check in the code than
risking a fatal error which is unstoppable...
I call this showstopper if we say that we are proud with the type-hinting.
Andrey
Quoting
On Mon, 8 Aug 2005, Andrey Hristov wrote:
Hmm,
I was complaining about inusaability ot type hinting because of this fatal
errors but nobody seems heard me :(. One better do a check in the code than
risking a fatal error which is unstoppable...
I call this showstopper if we say that we are
Hi Sebastian Bergmann!
On 08/08/05 13:32 you wrote:
Won't work, SPL can be disabled.
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
That's senseless when writing applications that shall be version
independant. Just sticking to Exception should
Hi Toby,
On Monday 08 August 2005 15:04, Tobias Schlitt wrote:
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
That's senseless when writing applications that shall be version
independant. Just sticking to Exception should be fine.
No it is
On Mon, 8 Aug 2005, Johannes Schlueter wrote:
On Monday 08 August 2005 15:04, Tobias Schlitt wrote:
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
That's senseless when writing applications that shall be version
independant. Just
Hi Johannes Schlueter!
On 08/08/05 14:50 you wrote:
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
That's senseless when writing applications that shall be version
independant. Just sticking to Exception should be fine.
No it is not, in your
Derick Rethans schrieb:
Throwing two different kinds of Exceptions is evil.
Just as evil as allowing SPL to be disabled.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals -
On Mon, 8 Aug 2005, Sebastian Bergmann wrote:
Derick Rethans schrieb:
Throwing two different kinds of Exceptions is evil.
Just as evil as allowing SPL to be disabled.
Not really. SPL is only for people that actually want to use Java.
Derick
--
Derick Rethans
http://derickrethans.nl |
On Mon, 8 Aug 2005 15:09:06 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Mon, 8 Aug 2005, Sebastian Bergmann wrote:
Derick Rethans schrieb:
Throwing two different kinds of Exceptions is evil.
Just as evil as allowing SPL to be disabled.
Not really. SPL is only for
Derick Rethans wrote:
On Mon, 8 Aug 2005, Sebastian Bergmann wrote:
Derick Rethans schrieb:
Throwing two different kinds of Exceptions is evil.
Just as evil as allowing SPL to be disabled.
Not really. SPL is only for people that actually want to use Java.
I thought that's what exceptions
Tobias Schlitt wrote:
Hi Johannes Schlueter!
On 08/08/05 14:50 you wrote:
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
That's senseless when writing applications that shall be version
independant. Just sticking to Exception should be fine.
On Mon, 08 Aug 2005 15:56:55 +0200
[EMAIL PROTECTED] (Jochem Maas) wrote:
IMHO btw, semantically, calling it S(tandard)PL and then making
it so that it's not standard (i.e. it's an extension) seems odd.
I was pretty sure until today that it was not possible to disable
it. But it's not possible
On Mon, 8 Aug 2005, Derick Rethans wrote:
On Mon, 8 Aug 2005, Sebastian Bergmann wrote:
Derick Rethans schrieb:
Throwing two different kinds of Exceptions is evil.
Just as evil as allowing SPL to be disabled.
Not really. SPL is only for people that actually want to use Java.
Hello Tobias,
Monday, August 8, 2005, 3:35:28 PM, you wrote:
Hi Johannes Schlueter!
On 08/08/05 14:50 you wrote:
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
That's senseless when writing applications that shall be version
independant. Just
Hello Derick,
Monday, August 8, 2005, 3:09:06 PM, you wrote:
On Mon, 8 Aug 2005, Sebastian Bergmann wrote:
Derick Rethans schrieb:
Throwing two different kinds of Exceptions is evil.
Just as evil as allowing SPL to be disabled.
Not really. SPL is only for people that actually want to
Hello Derick,
Monday, August 8, 2005, 3:00:50 PM, you wrote:
On Mon, 8 Aug 2005, Johannes Schlueter wrote:
On Monday 08 August 2005 15:04, Tobias Schlitt wrote:
The throw an Exception when SPL disabled and an InvalidArgumentException
when it is enabled.
That's senseless when
On Mon, 8 Aug 2005, Marcus Boerger wrote:
without SPL. At the end of the day i'd even like to drop reflection support
from the engine and move it to a specialized extensions - again - for
speed/memory reasons.
YES PLEASE! I've absolutely no use for it, and I really really need
every
Jani Taskinen wrote:
without SPL. At the end of the day i'd even like to drop reflection
support
from the engine and move it to a specialized extensions - again - for
speed/memory reasons.
YES PLEASE! I've absolutely no use for it, and I really really need
every bit of
Hi all,
Finally caught up with this thread.
I can live with an exception being thrown for a type hint. I think calling
it InvalidArgumentException would make sense, and the fact that Marcus
stole :) that name for SPL and didn't prefix the name isn't a reason for
us not to do the right
Hey Marcus,
What standard stuff? I remember SPL being used as a way to bring features
to users which were decided not to have as standards :) Anyway, we won't
get back into it as we've talked about it already in person. But anyway, if
we decide to have InvalidArgumentException as a standard
At 11:41 PM 8/8/2005 +0200, Derick Rethans wrote:
On Mon, 8 Aug 2005, Andi Gutmans wrote:
As far as implementation is concerned, it definitely should wait for
after PHP
5.1 and the patch should deal with the hard parts which are internal
functions
and overloaded functions. Implementing
Derick Rethans wrote:
On Mon, 8 Aug 2005, Andi Gutmans wrote:
As far as implementation is concerned, it definitely should wait for after PHP
5.1 and the patch should deal with the hard parts which are internal functions
and overloaded functions. Implementing this for user-functions is the
97 matches
Mail list logo
