[PHP-DEV] type hinting throwing a fatal error
Derick Rethans
currently if you pass a wrong object's type to a typehinted parameter:
derick@kossu:~$ cat /tmp/foo.php
<?php
class foo {
function bar(foo $a)
{
}
}
$a = new foo;
$a->bar(new stdClass);
?>
derick@kossu:~$ php /tmp/foo.php
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 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 annoying.
Opinions?
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sebastian Bergmann
> Opinions?
+1
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
David Zülke
> -----Original Message-----
> From: Derick Rethans [mailto:der...@php.net]
> 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:
>
> derick@kossu:~$ cat /tmp/foo.php
> <?php
> class foo {
> function bar(foo $a)
> {
> }
> }
>
> $a = new foo;
> $a->bar(new stdClass);
> ?>
> derick@kossu:~$ php /tmp/foo.php
>
> 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 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 annoying.
> Opinions?
>
> Derick
>
Derick Rethans
> Derick Rethans schrieb:
> > Opinions?
>
> +1
Does that mean you want more opinions? :)
regards,
Ondrej Ivanič
> Does that mean you want more opinions? :)
Throw an InvalidArgumentException from SPL...
--
Ondrej Ivanic
(ond...@kmit.sk)
Derick Rethans
Content-Type: TEXT/PLAIN; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Mon, 8 Aug 2005, Ondrej Ivani=C4=8D wrote:
> Derick Rethans wrote:
> > Does that mean you want more opinions? :)
>=20
> Throw an InvalidArgumentException from SPL...
Won't work, SPL can be disabled.
Derick
--8323328-1794936968-1123499445=:2940
Content-Type: text/plain; charset=us-ascii
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--8323328-1794936968-1123499445=:2940--
Sebastian Bergmann
> 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 B85B 5D69
--
Michael Sims
> 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 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
> annoying. Opinions?
As a PHP user, I have to say I wholeheartedly agree, and I'm glad someone is
raising this issue again. The last time it was seriously discussed:
http://marc.theaimsgroup.com/?l=php-dev&m=104878782529499&w=2
was less than encouraging.
As a user who is trying to write robust code, my biggest issue is not
whether or not a type hint violation throws an exception, but whether or not
it results in an error than I can trap for. An exception would be great,
obviously, but I'd be just as happy with an E_WARNING, so at the very least
my custom error handler can catch this. As you have pointed out, it's
currently a fatal error so a user-defined error handler is not called.
I don't typically comb through my server's php error logs, since I mainly
depend on my custom error handler to let me know when one of my applications
is having problems. Because of this I have been forced to avoid using type
hints and I've actually implemented by own function to simulate type hints,
like so:
/* @param SomeObject $foo */
public function someMethod($foo) {
checkArgType($foo, 'SomeObject');
}
checkArgType() throws an exception if $foo isn't instanceof 'SomeObject'.
I would MUCH rather use type hints here. They're cleaner from a
documentation standpoint and the wtf factor is much lower. Unfortunately I
can't as long as type hint violations are fatal.
So, I would be very happy if type hint violations either threw and exception
OR triggered an E_WARNING. As Wez pointed out in
http://marc.theaimsgroup.com/?l=php-dev&m=104911187824684&w=2, currently if
you pass the wrong number of arguments to a function/method you get an
E_WARNING (not a fatal error), so I don't see why type hint violations
shouldn't be treated similarly. It would increase their value and utility
immensely...
Markus Fischer
> 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 annoying.
> Opinions?
+1 on throwing an exception.
- Markus
Sebastian Bergmann
> 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 B85B 5D69
--
Derick Rethans
> 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.
Proof-of-concept patch is here:
http://files.derickrethans.nl/patches/typehint-reference-2005-08-08.diff.txt
(I need to clean up the message allocation stuff)
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Tobias Schlitt
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 be fine.
Regards,
--
Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579
a passion for php http://www.schlitt.info
Like to say "thank you"? - http://pear.php.net/wishlist.php/toby
Johannes Schlueter
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 not, in your application you can still simply catch Exception to be
independent of SPL since the InvalidArgumentException class extends the
Exception class. But by using nested Exceptions you can catch them
independently. Else you would have to catch every Exception, parse the error
message or trace to see wether it was a problem while calling the
function/method or some code inside the function/method went wrong.
<?php
function foo() {
$bar = ....;
try {
call_with_wrong_parameter($bar);
} catch (InvalidArgumentException $e) {
// bad function call...
}
}
try {
foo();
} catch (Exception $e) {
// any other exception
}
?>
I'd like to see something like what Sebastian suggested. And imho it wouldn't
really be a bc-break since an uncaught exception is fatal, too.
johannes
Tobias Schlitt
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 application you can still simply catch Exception to be
> independent of SPL since the InvalidArgumentException class extends the
> Exception class. But by using nested Exceptions you can catch them
> independently. Else you would have to catch every Exception, parse the error
> message or trace to see wether it was a problem while calling the
> function/method or some code inside the function/method went wrong.
The point is, that it's senseless to have it throw any exception that
can be disabled, when you want to write portable applications. In that
case you still have to stick to catch Exception and have no benefit of
it throwing anything else, when SPL is enabled.
I would pretty much appreciate it having thrown an
InvalidArgumentException, but then this should work everywhere.
Regards,
--
Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579
a passion for php http://www.schlitt.info
Like to say "thank you"? - http://pear.php.net/wishlist.php/toby
--
Sebastian Bergmann
> 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
--
Derick Rethans
> 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 | http://ez.no | http://xdebug.org
--
Pierre-Alain Joye
der...@php.net (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.
Wrong, and this is a stupid argument, sorry.
But this is another topic.
--Pierre
Derick Rethans
> 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 not, in your application you can still simply catch Exception to be
> independent of SPL since the InvalidArgumentException class extends the
> Exception class.
Throwing two different kinds of Exceptions is evil. It should be
consistent, not relying on an external component for it's exceptions. So
it will be a normal Exception. This is a useles branch of this tread -
and it should end now.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
Christian Schneider
> On Mon, 8 Aug 2005, Sebastian Bergmann wrote:
>
>>Derick Rethans schrieb:
>
> Not really. SPL is only for people that actually want to use Java.
I thought that's what exceptions are for (-:C
Sorry, couldn't resist and I promise to shut up again,
- Chris "exceptions are only simple if you don't use them" Schneider
Andrey Hristov
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 Derick Rethans <der...@php.net>:
> Hei,
>
> currently if you pass a wrong object's type to a typehinted parameter:
>
> derick@kossu:~$ cat /tmp/foo.php
> <?php
> class foo {
> function bar(foo $a)
> {
> }
> }
>
> $a = new foo;
> $a->bar(new stdClass);
> ?>
> derick@kossu:~$ php /tmp/foo.php
>
> 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 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 annoying.
> Opinions?
>
> Derick
Jochem Maas
> Hi Johannes Schlueter!
>
>
>>>>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 application you can still simply catch Exception to be
>>independent of SPL since the InvalidArgumentException class extends the
>>independently. Else you would have to catch every Exception, parse the error
>>message or trace to see wether it was a problem while calling the
>>function/method or some code inside the function/method went wrong.
>
>
> The point is, that it's senseless to have it throw any exception that
> can be disabled, when you want to write portable applications. In that
> case you still have to stick to catch Exception and have no benefit of
> it throwing anything else, when SPL is enabled.
>
> I would pretty much appreciate it having thrown an
> InvalidArgumentException, but then this should work everywhere.
I guess creating a new special exception (e.g. TypeHintException) that
extends Exception as part of the php core (as opposed to living in SPL)
is a stupid idea?
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.
>
> Regards,
Pierre-Alain Joye
joc...@iamjochem.com (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 to build dynamicly.
This is odd, to do not say stupid. What's about making really
standard?
Regards,
--Pierre
Jani Taskinen
> 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.
Enabling it by default is same as enabling unnecessary bloat by default.
So no thanks for making it not possible to disable..
--Jani
Marcus Boerger
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 sticking to Exception should be fine.
>> No it is not, in your application you can still simply catch Exception to be
>> independent of SPL since the InvalidArgumentException class extends the
>> Exception class. But by using nested Exceptions you can catch them
>> independently. Else you would have to catch every Exception, parse the error
>> message or trace to see wether it was a problem while calling the
>> function/method or some code inside the function/method went wrong.
> The point is, that it's senseless to have it throw any exception that
> can be disabled, when you want to write portable applications. In that
> case you still have to stick to catch Exception and have no benefit of
> it throwing anything else, when SPL is enabled.
> I would pretty much appreciate it having thrown an
> InvalidArgumentException, but then this should work everywhere.
If you plan to support PHP builds without SPL then that most likley means
that you have dropped other built-in default extensions too. Probably
because of their memory space to reduce loading time. In that case you are
not up for portability or have made a major mistake already in the
beginning.
Anyway there is no argument here. If you go for portable apps in the sense
that any extension can be diabled then catching plain Exceptions should be
more than good enough. You cannot expect to have full blown oo support when
you disable the one oo extension.
As a side note we could probably also move all exception declarations from
SPL to the engine but then we'd loose the possibility to support builds
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.
best regards
marcus
Marcus Boerger
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 writing applications that shall be version
>> > independant. Just sticking to Exception should be fine.
>>
>> No it is not, in your application you can still simply catch Exception to be
>> independent of SPL since the InvalidArgumentException class extends the
>> Exception class.
> Throwing two different kinds of Exceptions is evil. It should be
> consistent, not relying on an external component for it's exceptions. So
> it will be a normal Exception. This is a useles branch of this tread -
> and it should end now.
Throwing a pure Exception is useless. Since it is the nature of Exception
handling to code the reson into the Exception hierarchy. See my other reply
and the comment on moving the exceptions to the engine.
Best regards,
Marcus
Jani Taskinen
> 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 memory/speed/whatever I can get out of PHP..
--Jani
Tobias Schlitt
On 08/08/05 19:58 you wrote:
>>The point is, that it's senseless to have it throw any exception that
>>can be disabled, when you want to write portable applications. In that
>>case you still have to stick to catch Exception and have no benefit of
>>it throwing anything else, when SPL is enabled.
>>I would pretty much appreciate it having thrown an
>>InvalidArgumentException, but then this should work everywhere.
> If you plan to support PHP builds without SPL then that most likley means
> that you have dropped other built-in default extensions too. Probably
> because of their memory space to reduce loading time. In that case you are
> not up for portability or have made a major mistake already in the
> beginning.
> Anyway there is no argument here. If you go for portable apps in the sense
> that any extension can be diabled then catching plain Exceptions should be
> more than good enough. You cannot expect to have full blown oo support when
> you disable the one oo extension.
That's the point: OO extension. I agree that things like iterators and
stuff belong into SPL, since they're not standard OO features. But
things like predefined exceptions belong into the engine. Especially
those that get thrown by a PHP builtin feauture.
Not to get me wrong, I'm strongly against having extensions itself or
functions throw exceptions, but in the case we currently discuss, we are
dealing with an OO feature of PHP, that should definitly throw it's own
exception. Why else were exceptions invented when not to be used with OO
features?
> As a side note we could probably also move all exception declarations from
> SPL to the engine but then we'd loose the possibility to support builds
> 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.
Having all exceptions in the engine sounds much overhead. But some well
defined ones that get utilized by PHP OO features would definitly make
sense.
In the end, I have not a real problem with any solution, as long as OO
features start throwing exceptions instead of raising errors. :)
Regards,
Toby
--
Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579
a passion for php http://www.schlitt.info
Like to say "thank you"? - http://pear.php.net/wishlist.php/toby
--
Marcus Boerger
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 use Java.
The stupiest thing you could have come up with.
If it were about Java it was unusable and slow.
You see t hat's the same bullshit and doesn't belong here - very contra
productive.
Best regards,
Marcus
Ondrej Ivanič
>> 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.
>
>
> every bit of memory/speed/whatever I can get out of PHP..
Wow!
Is PHP the right tool for you?
If you don't use 00 things you can stay on PHP 4.x with ZE1. What you
need/don't from PHP?
It will be useful to move some parts of Exception hierarchy from SPL to
ZE2, but from PHP 5.1 SPL it will be use full to move everything :)
--
Ondrej Ivanic
(ond...@kmit.sk)
Jani Taskinen
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
On Mon, 8 Aug 2005, Ondrej IvaniÄ wrote:
> 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 memory/speed/whatever I can get out of PHP..
>
> Wow!
> Is PHP the right tool for you?
I think I know what is right or not for me. =)
> If you don't use 00 things you can stay on PHP 4.x with ZE1. What you
> need/don't from PHP?
Ehehehehhehheheheee...
--Jani
--8323328-1589184928-1123533296=:31434
Content-Type: text/plain; charset=us-ascii
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--8323328-1589184928-1123533296=:31434--
Andi Gutmans
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 thing... As it would be an engine exception, we'd
move it to the Engine. This is a good reason why extensions such as SPL
should prefix their functionality.
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 easier part. There might be some gotchas (as usual) with internal
functions throwing exceptions.
On a whole though, I do recommend to relax on the
"add-every-oo-feature-that-exists" to the PHP code base, because it'll lead
to PHP loosing its ease-of-use. The namespace proposal (which I haven't
replied to yet) is a prime example. I saw all sorts of Java-like stuff like
private classes which in my opinion would just over-complicate our model
which already has become quite rich. We should only add what we really
think PHP users need, and not stuff which is nice because it's OOpier. I do
think that if we can get it right, a basic namespace model would be useful,
but it all depends wether we can avoid the problems we had in the past
*and* keep it simple!
Andi
P.S. - Derick, out of curiosity, what made you ask for an Exception? I
thought you don't use OOP, and definitely not evil try/catch constructs? :)
Derick Rethans
> 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 easier
> part. There might be some gotchas (as usual) with internal functions throwing
> exceptions.
Yeah, but afaik all cases *should* use this function
'zend_verify_arg_type', if not, that needs to be fixed.
> On a whole though, I do recommend to relax on the
> "add-every-oo-feature-that-exists" to the PHP code base, because it'll lead to
> PHP loosing its ease-of-use. The namespace proposal (which I haven't replied
> to yet) is a prime example. I saw all sorts of Java-like stuff like private
> classes which in my opinion would just over-complicate our model which already
> has become quite rich. We should only add what we really think PHP users need,
> and not stuff which is nice because it's OOpier. I do think that if we can get
> it right, a basic namespace model would be useful, but it all depends wether
> we can avoid the problems we had in the past *and* keep it simple!
Right, I definitely agree there.
> P.S. - Derick, out of curiosity, what made you ask for an Exception? I thought
> you don't use OOP, and definitely not evil try/catch constructs? :)
I prefer not to comment on that :)
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
Andi Gutmans
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 (which was not the
case for most of SPL), then it definitely will make sense to move it to the
Engine as the engine will need to know it. Features which make sense to
remain as an SPL extension should be treated like a PHP extension.
"non-standard" stuff shouldn't be prefixed to make me personally happy. I
think it should be prefixed to make everyone happy, follow coding standards
and follow the same rules as everyone.
Andi
At 11:43 PM 8/8/2005 +0200, Marcus Boerger wrote:
>Hello Andi,
>
>Monday, August 8, 2005, 11:33:16 PM, you wrote:
>
> > 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 thing... As it would be an engine exception, we'd
> > move it to the Engine. This is a good reason why extensions such as SPL
> > should prefix their functionality.
>
>SPL delivers those standard stuff not delivered by the engine so it makes no
>sense to prefix them with an SPL prefix. Non standrd stuff will have SPL
>prefix in future though just to make you happy. Having said that i think
>that extension tree belongs either in the engine or stays in the extension
>and we go with pure Exception. Remember the reason i out this into SPL in
>the first place was to be able to drop all that fancy O stuff. In that sense
>i also asked to move reflection api into its own extension, that way adding
>another possibility to drop memory space of the excecutable, increasing exe
>load time and thereby increasing speed of such special builds.
>
>Best regards,
> Marcus
Andi Gutmans
>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
> easier
> > part. There might be some gotchas (as usual) with internal functions
> throwing
> > exceptions.
>
>Yeah, but afaik all cases *should* use this function
>'zend_verify_arg_type', if not, that needs to be fixed.
Yep, problem starts not when you identify and raise the exception but when
you have to return to the engine and allow it to propogate.
Andi
> > On a whole though, I do recommend to relax on the
> > "add-every-oo-feature-that-exists" to the PHP code base, because it'll
> lead to
> > PHP loosing its ease-of-use. The namespace proposal (which I haven't
> replied
> > to yet) is a prime example. I saw all sorts of Java-like stuff like private
> > classes which in my opinion would just over-complicate our model which
> already
> > has become quite rich. We should only add what we really think PHP
> users need,
> > and not stuff which is nice because it's OOpier. I do think that if we
> can get
> > it right, a basic namespace model would be useful, but it all depends
> wether
> > we can avoid the problems we had in the past *and* keep it simple!
>
>Right, I definitely agree there.
>
> > P.S. - Derick, out of curiosity, what made you ask for an Exception? I
> thought
> > you don't use OOP, and definitely not evil try/catch constructs? :)
>
>I prefer not to comment on that :)
>
>Derick
>
>--
>Derick Rethans
>http://derickrethans.nl | http://ez.no | http://xdebug.org
--
Marcus Boerger
Monday, August 8, 2005, 11:33:16 PM, you wrote:
> 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 thing... As it would be an engine exception, we'd
> move it to the Engine. This is a good reason why extensions such as SPL
> should prefix their functionality.
SPL delivers those standard stuff not delivered by the engine so it makes no
sense to prefix them with an SPL prefix. Non standrd stuff will have SPL
prefix in future though just to make you happy. Having said that i think
that extension tree belongs either in the engine or stays in the extension
and we go with pure Exception. Remember the reason i out this into SPL in
the first place was to be able to drop all that fancy O stuff. In that sense
i also asked to move reflection api into its own extension, that way adding
another possibility to drop memory space of the excecutable, increasing exe
load time and thereby increasing speed of such special builds.
Best regards,
Marcus
--
Andrey Hristov
> 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 easier
>>part. There might be some gotchas (as usual) with internal functions throwing
>>exceptions.
>
>
> Yeah, but afaik all cases *should* use this function
> 'zend_verify_arg_type', if not, that needs to be fixed.
>
>
>>"add-every-oo-feature-that-exists" to the PHP code base, because it'll lead to
>>PHP loosing its ease-of-use. The namespace proposal (which I haven't replied
>>to yet) is a prime example. I saw all sorts of Java-like stuff like private
>>classes which in my opinion would just over-complicate our model which already
>>has become quite rich. We should only add what we really think PHP users need,
>>and not stuff which is nice because it's OOpier. I do think that if we can get
>>it right, a basic namespace model would be useful, but it all depends wether
>>we can avoid the problems we had in the past *and* keep it simple!
>
>
> Right, I definitely agree there.
>
>
>>P.S. - Derick, out of curiosity, what made you ask for an Exception? I thought
>>you don't use OOP, and definitely not evil try/catch constructs? :)
>
>
> I prefer not to comment on that :)
>
> Derick
>
Probably better a catchable exception than uncatchable Fatal error :)
Andrey
Sebastian Bergmann
> 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
--
Derick Rethans
> 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
--
Zeev Suraski
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 is very messy. Type hinting is also not
exactly an OO thing, it's an object thing, and there's a difference. PHP
is filling up with a lot of builtin classes, as well as infrastructure
classes, that actually simplify the lives of users, without them having to
have a clue about object orientation. Some examples that come to mind are
SimpleXML, the SOAP classes and PDO. On a long enough timescale -
everybody using PHP will be using objects, and many (if not most) of them
will be using them in procedural apps. I see a big negative point in
forcibly introducing these people to the concept of exceptions.
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).
Zeev
At 12:50 08/08/2005, Derick Rethans wrote:
>Hei,
>
>currently if you pass a wrong object's type to a typehinted parameter:
>
> derick@kossu:~$ cat /tmp/foo.php
> <?php
> class foo {
> function bar(foo $a)
> {
> }
> }
>
> $a = new foo;
> $a->bar(new stdClass);
> ?>
> derick@kossu:~$ php /tmp/foo.php
>
> 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 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 annoying.
>Opinions?
>
>Derick
>
Tobias Schlitt
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 into a fatal error. Therefore
you do not force anyone to actually write 'exception-oriented' apps.
> 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.
> That is a good idea (which we should be doing either way).
I definitly agree here, but it does not make sense for type hinting.
But heaving the type hints throwing an exception is a really nice
feature for large applications, where you are often not sure, which
parts of the application will call a function or even worse you're not
sure with which objects you act (because of utilizing multiple different
libraries, written be even more different people). Having an exception
thrown in that case enables you to run surrounded, independant modules
to finish their work gracefully instead of shutting down the whole
request gracefully.
The actual implementation of type hints does not allow them to be used
in this case, because having a coding error in just 1 module will screw
up all other modules, where just 1 is broken.
Regards,
Toby
--
Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579
a passion for php http://www.schlitt.info
Like to say "thank you"? - http://pear.php.net/wishlist.php/toby
--
Andrey Hristov
Andrey
--
Zeev Suraski
>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 into a fatal error. Therefore
>you do not force anyone to actually write 'exception-oriented' apps.
Did I say 'force'? I said 'encourage'. The text of an uncaught exception
mentions, well, an uncaught exception. What the heck does that mean? What
is an exception and why did it run away? It would encourage people to
start learning what exceptions are, a non trivial concept at the least, and
one of the first things they'll see is that they can trap them with try/catch.
> > 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 encourage (<-- not force)
you to write code that recovers from exceptions, but rather - a trap-all
just-in-case-something-goes-really-wrong error message.
> > That is a good idea (which we should be doing either way).
>
>I definitly agree here, but it does not make sense for type hinting.
>
>But heaving the type hints throwing an exception is a really nice
>feature for large applications, where you are often not sure, which
>parts of the application will call a function or even worse you're not
>sure with which objects you act (because of utilizing multiple different
>libraries, written be even more different people). Having an exception
>thrown in that case enables you to run surrounded, independant modules
>to finish their work gracefully instead of shutting down the whole
>request gracefully.
>
>The actual implementation of type hints does not allow them to be used
>in this case, because having a coding error in just 1 module will screw
>up all other modules, where just 1 is broken.
Well, like I said - sorry, but I consider that statement wrong :) I
definitely think that this type of error is the one that is caught during
development, and not during runtime, and is fixed as soon as it's
found. Writing advanced 'let's try to call this, and if it fails do that'
is exactly the kind of stuff I'm trying to avoid. If you really want to do
that - you can use the ultra advanced approach and use reflection.
Zeev
Zeev Suraski
>On Thu, 11 Aug 2005, Derick Rethans wrote:
>
> > > I believe we mentioned once the possibility of adding another error
> level,
> > > idea (which we should be doing either way).
> >
>
>Except that it shouldn't be able to stop the application. The reason for
>this is that Unit Testing on this stuff should still work, and you can't
>always anticipate what your users do with your libraries. If a user
>does something wrong in a third party module to your application,
>and pass a wrong opbject to one of your utility classes, when we do
>not want the whole application to stop immediately, as it might be
>just a sub-part of you application which is very possible to ignore
>for the full working of your application. This is why
>I first suggested an exception, so that the application can continue.
>Although in *my* opinion the application just should blow up, other
>people disagree with me here.
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...
Derick Rethans
> 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 fine too.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
Christian Schneider
>> > I believe we mentioned once the possibility of adding another error
>> > level, which is fatal - but still catchable by set_error_handler().
>>
>> application.
>
> Right, which is infinitely better. It does not encourage (<-- not
> force) you to write code that recovers from exceptions, but rather - a
> trap-all just-in-case-something-goes-really-wrong error message.
Catch-alls are bad but... There is an even worse case: People start
abusing exceptions for flow control/ normal operation like replacing
something like "if ($obj) foo($obj)" with "try { foo($obj); } catch
(Exception $e) {}" because the error message mentions exceptions and/or
because they just learned about it and think it's cool.
If you guys decide to go forward and use an exception for type hinting
(which is a tad more powerful, agreed) then at least make the exception
message very clear that the caller of the function should make sure he
passes the proper object type to the function, NOT that if should be
wrapped in try/catch.
My $.02,
- Chris
Lukas Smith
> On Thu, 11 Aug 2005, Derick Rethans wrote:
>
>
>>>I believe we mentioned once the possibility of adding another error level,
>>>idea (which we should be doing either way).
>>
>>That would work well. I just want the type hints to be catchable.
>
>
> Except that it shouldn't be able to stop the application. The reason for
> this is that Unit Testing on this stuff should still work, and you can't
Well UnitTests should always be run in a separate process, so that you
can infact to proper edge (or even over the edge) testing.
regards,
Lukas
Derick Rethans
> 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 is very messy. Type hinting is also not
> exactly an OO thing, it's an object thing, and there's a difference. PHP is
> filling up with a lot of builtin classes, as well as infrastructure classes,
> that actually simplify the lives of users, without them having to have a clue
> about object orientation. Some examples that come to mind are SimpleXML, the
> SOAP classes and PDO. On a long enough timescale - everybody using PHP will
> be using objects, and many (if not most) of them will be using them in
> procedural apps. I see a big negative point in forcibly introducing these
> people to the concept of exceptions.
I agree a 100% here.
> 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 to be catchable.
regards,
Derick
Derick Rethans
> > 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 to be catchable.
Except that it shouldn't be able to stop the application. The reason for
this is that Unit Testing on this stuff should still work, and you can't
always anticipate what your users do with your libraries. If a user
does something wrong in a third party module to your application,
and pass a wrong opbject to one of your utility classes, when we do
not want the whole application to stop immediately, as it might be
just a sub-part of you application which is very possible to ignore
for the full working of your application. This is why
I first suggested an exception, so that the application can continue.
Although in *my* opinion the application just should blow up, other
people disagree with me here.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
Derick Rethans
> 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 want the type hints to be catchable.
> >
> > Except that it shouldn't be able to stop the application. The reason for
> > this is that Unit Testing on this stuff should still work, and you can't
>
> Well UnitTests should always be run in a separate process, so that you can
> infact to proper edge (or even over the edge) testing.
I agree, but none of the Unit Test frameworks (except php-tests) do
this. I don't think I should be rewriting yet another one.