Everything

php

Home » Project » Newsgroups » php.internals » Type hints revisited [IllegalArgumentException instead of E_ERROR] »

Type hints revisited [IllegalArgumentException instead of E_ERROR]

php.internals

Timm Friebe

23 years ago

I've implemented an additional feature for type hints that will throw an
exception instead of bailing out in case an incorrect type is passed.

Test script:

<?php
class Date { }
class Article {
public function setCreated_at(Date $date) {
echo __CLASS__, '::', __FUNCTION__, ' called with ';
var_export($date);
echo "\n";
}

public function setLastchange([Date] $date) {
echo __CLASS__, '::', __FUNCTION__, ' called with ';
var_export($date);
echo "\n";
}
}

$a= new Article();
$a->setLastchange(new Date());
$a->setLastchange(NULL);  // Passes
$a->setCreated_at(new Date());

try {
$a->setCreated_at(NULL);  // Fails
} catch (IllegalArgumentException $e) {
echo "Caught: "; var_dump($e);
}

$a->setCreated_at(1); // Fails
echo "Alive";         // Will not show up
?>

Output:
---------------------------------------------------------------------
thekid@friebes:~/devel/php > ./php5/sapi/cli/php hints.php
article::setlastchange called with class date {
}
article::setlastchange called with NULL
article::setcreated_at called with class date {
}
Caught: object(illegalargumentexception)#2 (3) {
["message"]=>
string(38) "Argument 1 must be an instance of date"
["file"]=>
string(36) "/usr/home/thekid/devel/php/hints.php"
["line"]=>
int(4)
}

Fatal error: Uncaught exception! in Unknown on line 0
---------------------------------------------------------------------

A unified diff is attached.

- Timm

Andi Gutmans

23 years ago

At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:

>I've implemented an additional feature for type hints that will throw an
>exception instead of bailing out in case an incorrect type is passed.

I don't see any major advantage in doing this. I think we should keep PHP
error handling the same as in PHP 4 and leave exceptions in user-land.
Otherwise we'll end up having an unmanageable hybrid because there's no way
we're going to change the error-handling of the existing internal
functions. The majority of our user base is still functional, please don't
forget this. I feel that people here tend to forget that.

Andi

George Schlossnagle

23 years ago

On Thursday, March 27, 2003, at 11:58  AM, Andi Gutmans wrote:

> At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
>> I've implemented an additional feature for type hints that will throw
>> an
>> exception instead of bailing out in case an incorrect type is passed.
>
> I don't see any major advantage in doing this. I think we should keep
> PHP error handling the same as in PHP 4 and leave exceptions in
> user-land. Otherwise we'll end up having an unmanageable hybrid
> because there's no way we're going to change the error-handling of the
> existing internal functions. The majority of our user base is still
> functional, please don't forget this. I feel that people here tend to
> forget that.

I think this can(all) be handled with a custom zend_error_cb anyway (in
an extension - so that it's available only if you want it.)  Looks
really simple to implement too.

George

Timm Friebe

23 years ago

On Thu, 2003-03-27 at 18:04, George Schlossnagle wrote:

> On Thursday, March 27, 2003, at 11:58  AM, Andi Gutmans wrote:

[...]

> I think this can(all) be handled with a custom zend_error_cb anyway (in
> an extension - so that it's available only if you want it.)  Looks
> really simple to implement too.

Well, I can think fo the following disadvantages to that:
- Code is less portable (some other user or ISP might not have the
fancy --with-cool-oop extension enabled)

- Within zend_error, all information is lost about the error context.
E.g., if you handle E_ERROR, you will not know if it was an illegal
argument, a call to a member function of a non-object or whatever
else. You only know it was a fatal error.

- Current code relies on the fact that zend_error(E_ERROR, [...]) bails
out. If you start throwing around exceptions instead, this will
probably end up in a big mess:)

Just my 3 cents: Timm

George Schlossnagle

23 years ago

On Thursday, March 27, 2003, at 12:10  PM, Timm Friebe wrote:

> On Thu, 2003-03-27 at 18:04, George Schlossnagle wrote:
>> On Thursday, March 27, 2003, at 11:58  AM, Andi Gutmans wrote:
> [...]
>> I think this can(all) be handled with a custom zend_error_cb anyway
>> (in
>> an extension - so that it's available only if you want it.)  Looks
>> really simple to implement too.
>
> Well, I can think fo the following disadvantages to that:
> - Code is less portable (some other user or ISP might not have the
>   fancy --with-cool-oop extension enabled)

Well, as Andi said, most people do not use oop with php.  Having the
same thing available as a php.ini toggle would be just as easy, but
doesn't sound like it would be popular.

>
> - Within zend_error, all information is lost about the error context.
>   E.g., if you handle E_ERROR, you will not know if it was an illegal
>   argument, a call to a member function of a non-object or whatever
>   else. You only know it was a fatal error.

This isn't completely true.

>
> - Current code relies on the fact that zend_error(E_ERROR, [...]) bails
>   out. If you start throwing around exceptions instead, this will
>   probably end up in a big mess:)

Well, if you don't handle E_ERRORs correctly it will fuck things up.
It's an exception, it means something broke.  There's no reason why you
can't recover/or at least gracefully handle most non-compile E_ERRORs,
you just need to handle it correctly.  If you don't you get what you're
asking for.

Sterling Hughes

23 years ago

On Thu, 2003-03-27 at 12:52, George Schlossnagle wrote:

> On Thursday, March 27, 2003, at 12:10  PM, Timm Friebe wrote:
>
> > On Thu, 2003-03-27 at 18:04, George Schlossnagle wrote:
> >> On Thursday, March 27, 2003, at 11:58  AM, Andi Gutmans wrote:
> > [...]
> >> I think this can(all) be handled with a custom zend_error_cb anyway
> >> (in
> >> an extension - so that it's available only if you want it.)  Looks
> >> really simple to implement too.
> >
> > Well, I can think fo the following disadvantages to that:
> > - Code is less portable (some other user or ISP might not have the
> >   fancy --with-cool-oop extension enabled)
>
> Well, as Andi said, most people do not use oop with php.  Having the
> same thing available as a php.ini toggle would be just as easy, but
> doesn't sound like it would be popular.
>
> >

Just a note on this.  People have avoided OO cause OO sucked.

Exceptions themselves are *incredibly* useful, especially when dealing
with database code (the majority of php applications), so I think you'll
see that portion of php used quite a bit.  I know personally I'll stay
very procedural, but almost all error handling will be done with try { }
catch { }.

-Sterling

--
"First they ignore you, then they laugh at you,
then they fight you, then you win."
- Gandhi

Andi Gutmans

23 years ago

At 12:37 PM 3/27/2003 -0500, Sterling Hughes wrote:

>Just a note on this.  People have avoided OO cause OO sucked.
>
>Exceptions themselves are *incredibly* useful, especially when dealing
>with database code (the majority of php applications), so I think you'll
>see that portion of php used quite a bit.  I know personally I'll stay
>very procedural, but almost all error handling will be done with try { }
>catch { }.

Yeah but you don't need incorrect function calls to throw exceptions. I'm
sure that's not what you're meaning to use them for.

Andi

Sterling Hughes

23 years ago

On Thu, 2003-03-27 at 13:13, Andi Gutmans wrote:

> At 12:37 PM 3/27/2003 -0500, Sterling Hughes wrote:
>
> >Just a note on this.  People have avoided OO cause OO sucked.
> >
> >Exceptions themselves are *incredibly* useful, especially when dealing
> >with database code (the majority of php applications), so I think you'll
> >see that portion of php used quite a bit.  I know personally I'll stay
> >very procedural, but almost all error handling will be done with try { }
> >catch { }.
>
> Yeah but you don't need incorrect function calls to throw exceptions. I'm
> sure that's not what you're meaning to use them for.
>

not at all.  I was more refering to the usefulness of george's patch.

-Sterling

> Andi

--
"A business that makes nothing but money is a poor kind of business."
- Henry Ford

Timm Friebe

23 years ago

On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote:

> At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
> >I've implemented an additional feature for type hints that will throw an
> >exception instead of bailing out in case an incorrect type is passed.
>
> I don't see any major advantage in doing this. I think we should keep PHP
> error handling the same as in PHP 4 and leave exceptions in user-land.
> Otherwise we'll end up having an unmanageable hybrid because there's no way
> we're going to change the error-handling of the existing internal
> functions. The majority of our user base is still functional, please don't
> forget this. I feel that people here tend to forget that.

Well, the problem about E_ERROR is, of course, that it bails out
instantaneously and there is no way to catch it in userland.

I unsterstand your arguments, though, but since type hints are for
classes only ATM (it was argued against being able to hint simple,
scalar types), we're in OO-land anyway; and there, Exceptions prevail
over warnings and/or errors:)

- Timm

Per Lundberg

23 years ago

On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote:

> At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
> >I've implemented an additional feature for type hints that will throw an
> >exception instead of bailing out in case an incorrect type is passed.
> I don't see any major advantage in doing this.

How about being able to handle errors in a clean and elegant way?
Exceptions make this very convenient.

Of course, it should not be done in a way to break backward
compatibility if at all possible.

> I think we should keep PHP error handling the same as in PHP 4 and
> leave exceptions in user-land.

This is a very bad idea.  One of the points of exceptions is being able
to have a standardized way of handling errors.  I also like the way Java
does it: if you don't catch the exceptions your code could throw, your
code won't even compile.  Now, I am pretty certain that you would not be
happy if I said this would be neat to have in PHP.  :-)  Still, I think
it would be great to have it as a configuration directive, because it
really is a Good Thing to force programmers to handle errors properly...

> Otherwise we'll end up having an unmanageable hybrid because there's no way
> we're going to change the error-handling of the existing internal
> functions. The majority of our user base is still functional, please don't
> forget this. I feel that people here tend to forget that.

It is true that many people still write imperative (function-based)
code.  But that is no argument for not making PHP a really, really good
Java-killer.  And, standardized exceptions is really one of the things I
find absoutely best in Java.  Yes, it is awkward in the beginning to
always have to try { } catch (or add Throws to your methods), but the
benefits are tremendeous.

Yes, the more I think about it I realize that this is big changes we are
talking about.  Basically, if we were to make all PHP internal functions
throw exceptions on errors, we might as well make them all be static
methods in a global PHP object... and that would break all backward
compatibility.  But maybe there would be a way to do it without breaking
all BC?

I hope this email will not start a long flamewar about why OOP is
bad/good.  Some people will obviously hate it and others love it.  But I
really, really do believe that if we want PHP to be the best programming
environment available, we need to take these issues into serious
consideration.  Many of the OOP problems of PHP4 have already been fixed
in PHP5.  Yet, there is still some room for improvement.

Maybe just have a big configuration switch called "php_oop" that is set
to "true" if the user prefers a OOP-based PHP, and "false" otherwise.
Possibly, and perhaps a better alternative, adding a new mime type
called "application/x-httpd-ohp" with file endings of .ohp, for
(puristic) object-oriented code.  That might not actually be a bad idea,
because it could keep the best of both worlds.

Just my $0.02.  ;-)

--
With all due respect,

Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.capio.com

Shane Caraveo

23 years ago

Well, if set_error_handler could catch E_ERROR errors (and not bail),
then errors could be changed to exceptions in user space.  I already use
this in the soap library to catch invalid parameters, which I beleive
are only warnings.  Not being able to catch exceptions on type hints
will make them pretty useless to me.

Shane

Andi Gutmans wrote:

Andi Gutmans

23 years ago

At 06:13 PM 3/27/2003 +0100, Timm Friebe wrote:

>On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote:
> > At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
> > >I've implemented an additional feature for type hints that will throw an
> > >exception instead of bailing out in case an incorrect type is passed.
> >
> > I don't see any major advantage in doing this. I think we should keep PHP
> > error handling the same as in PHP 4 and leave exceptions in user-land.
> > Otherwise we'll end up having an unmanageable hybrid because there's no
> way
> > we're going to change the error-handling of the existing internal
> > functions. The majority of our user base is still functional, please don't
> > forget this. I feel that people here tend to forget that.
>
>Well, the problem about E_ERROR is, of course, that it bails out
>instantaneously and there is no way to catch it in userland.

I consider calling a function with the wrong arguments a fatal error. A
compiled language would usually barf already during the compilation stage.
Therefore, I think E_ERROR is appropriate.

>I unsterstand your arguments, though, but since type hints are for
>classes only ATM (it was argued against being able to hint simple,
>scalar types), we're in OO-land anyway; and there, Exceptions prevail
>over warnings and/or errors:)

I think even the slightly more advanced functional programs might like some
of the OO encapsulation. But I think there's still a big difference between
using a class to encapsulate a database object and starting to throw
exceptions, using interfaces and so on. I don't want to force the average
PHP developer in this direction and I'd like to stay consistent with
today's E_ERROR handling.

Andi

Andi Gutmans

23 years ago

At 09:42 AM 3/27/2003 -0800, Shane Caraveo wrote:

>Well, if set_error_handler could catch E_ERROR errors (and not bail), then
>errors could be changed to exceptions in user space.  I already use this
>in the soap library to catch invalid parameters, which I beleive are only
>warnings.  Not being able to catch exceptions on type hints will make them
>pretty useless to me.

Now that is a very strong statement. I consider type hints useful syntactic
sugar but I don't think that it's useless if it doesn't throw an exception.
If soap is a special case because of its nature, then don't use type hints
and check their type and throw an exception in user-land.

Andi

Shane Caraveo

23 years ago

Andi Gutmans wrote:

> At 09:42 AM 3/27/2003 -0800, Shane Caraveo wrote:
>
>> Well, if set_error_handler could catch E_ERROR errors (and not bail),
>> then errors could be changed to exceptions in user space.  I already
>> use this in the soap library to catch invalid parameters, which I
>> beleive are only warnings.  Not being able to catch exceptions on type
>> hints will make them pretty useless to me.
>
>
> Now that is a very strong statement. I consider type hints useful
> syntactic sugar but I don't think that it's useless if it doesn't throw
> an exception.

>
> Andi

Strong to make the point, and not only useless to me, but to anyone
using OO with SOAP.  It prevents a proper SOAPFault from being returned
by the server.  There is no reason for this to be E_ERROR, we're not a
compiled language.  And I'm not arguing for hints to thow exceptions,
just for them to be 'catchable' via the regular error handlers, rather
than bailing PHP.

> If soap is a special case because of its nature, then don't use type
> hints and check their type and throw an exception in user-land.

Doing stuff in userland is fine, but type hints would simplify code and
remove the need to do that in user land.  Of course, so would operator
overloading.

Shane

Andi Gutmans

23 years ago

At 10:27 AM 3/27/2003 -0800, Shane Caraveo wrote:

>Andi Gutmans wrote:
>>At 09:42 AM 3/27/2003 -0800, Shane Caraveo wrote:
>>
>>>Well, if set_error_handler could catch E_ERROR errors (and not bail),
>>>then errors could be changed to exceptions in user space.  I already use
>>>this in the soap library to catch invalid parameters, which I beleive
>>>are only warnings.  Not being able to catch exceptions on type hints
>>>will make them pretty useless to me.
>>
>>Now that is a very strong statement. I consider type hints useful
>>syntactic sugar but I don't think that it's useless if it doesn't throw
>>an exception.
>
>>Andi
>
>Strong to make the point, and not only useless to me, but to anyone using
>OO with SOAP.  It prevents a proper SOAPFault from being returned by the
>server.  There is no reason for this to be E_ERROR, we're not a compiled
>language.  And I'm not arguing for hints to thow exceptions, just for them
>to be 'catchable' via the regular error handlers, rather than bailing PHP.
>
> > If soap is a special case because of its nature, then don't use type
> > hints and check their type and throw an exception in user-land.
>
>Doing stuff in userland is fine, but type hints would simplify code and
>remove the need to do that in user land.  Of course, so would operator
>overloading.

All I'm saying is that for a specialized extension such as SOAP (there
aren't and won't be many such extensions) it is fine to do some extra work.
We have to aim at the mainstream of PHP developers.

Andi

Andi Gutmans

23 years ago

At 06:20 PM 3/27/2003 +0100, Per Lundberg wrote:

>On Thu, 2003-03-27 at 17:58, Andi Gutmans wrote:
> > At 05:16 PM 3/27/2003 +0100, Timm Friebe wrote:
> > >I've implemented an additional feature for type hints that will throw an
> > >exception instead of bailing out in case an incorrect type is passed.
> > I don't see any major advantage in doing this.
>
>How about being able to handle errors in a clean and elegant way?
>Exceptions make this very convenient.

We have an error handler.

>Of course, it should not be done in a way to break backward
>compatibility if at all possible.

I consider having half of PHP throw errors and the other half as throwing
exceptions to break BC.

> > I think we should keep PHP error handling the same as in PHP 4 and
> > leave exceptions in user-land.
>
>This is a very bad idea.  One of the points of exceptions is being able
>to have a standardized way of handling errors.  I also like the way Java
>does it: if you don't catch the exceptions your code could throw, your
>code won't even compile.  Now, I am pretty certain that you would not be
>happy if I said this would be neat to have in PHP.  :-)  Still, I think
>it would be great to have it as a configuration directive, because it
>really is a Good Thing to force programmers to handle errors properly...

If you are looking for a strictly typed language I'd suggest Java :)
We (as in almost everyone) agree that configuration directives should not
be added because we want all scripts to run on all PHP enabled servers.

> > Otherwise we'll end up having an unmanageable hybrid because there's no
> way
> > we're going to change the error-handling of the existing internal
> > functions. The majority of our user base is still functional, please don't
> > forget this. I feel that people here tend to forget that.
>
>It is true that many people still write imperative (function-based)
>code.  But that is no argument for not making PHP a really, really good
>Java-killer.  And, standardized exceptions is really one of the things I
>find absoutely best in Java.  Yes, it is awkward in the beginning to
>always have to try { } catch (or add Throws to your methods), but the
>benefits are tremendeous.

We are not in the business of killing Java. We are in the business of being
the best web programming language. Although Java has some web "scripting"
standards such as JSP and Servlets the languages are not in competition.
One is a strictly typed compiled language and the other (PHP) a dynamically
typed scripting language. The reason for PHP's wide adoption is its ease of
use, especially vs. strongly typed languages such as Java. I want to keep
this advantage.

>Yes, the more I think about it I realize that this is big changes we are
>talking about.  Basically, if we were to make all PHP internal functions
>throw exceptions on errors, we might as well make them all be static
>methods in a global PHP object... and that would break all backward
>compatibility.  But maybe there would be a way to do it without breaking
>all BC?
>
>I hope this email will not start a long flamewar about why OOP is
>bad/good.  Some people will obviously hate it and others love it.  But I
>really, really do believe that if we want PHP to be the best programming
>environment available, we need to take these issues into serious
>consideration.  Many of the OOP problems of PHP4 have already been fixed
>in PHP5.  Yet, there is still some room for improvement.

You might call it improvement and some might call it bloat. Yes, the
important problems with the OOP models have been fixed. I don't think we
should "improve" PHP until it becomes Java. If that's what you want then
java is a URL away. People here tend to look at Java as the ideal, so if
that's the case, maybe PHP isn't for them.

>Maybe just have a big configuration switch called "php_oop" that is set
>to "true" if the user prefers a OOP-based PHP, and "false" otherwise.
>Possibly, and perhaps a better alternative, adding a new mime type
>called "application/x-httpd-ohp" with file endings of .ohp, for
>(puristic) object-oriented code.  That might not actually be a bad idea,
>because it could keep the best of both worlds.

See above why I'm am strongly against this.

>Just my $0.02.  ;-)

That was more like $10.00 :)

Andi

Per Lundberg

23 years ago

On Thu, 2003-03-27 at 19:07, Andi Gutmans wrote:

> >How about being able to handle errors in a clean and elegant way?
> >Exceptions make this very convenient.
> We have an error handler.

Context-local error handling is much more convenient (not to mention the
elegance of being able to handle errors in "userspace").

> >Of course, it should not be done in a way to break backward
> >compatibility if at all possible.
> I consider having half of PHP throw errors and the other half as throwing
> exceptions to break BC.

Even though we are talking about functionalites (type hints) that was
not even available in previous versions of PHP?

> >This is a very bad idea.  One of the points of exceptions is being able
> >to have a standardized way of handling errors.  I also like the way Java
> >does it: if you don't catch the exceptions your code could throw, your
> >code won't even compile.  Now, I am pretty certain that you would not be
> >happy if I said this would be neat to have in PHP.  :-)  Still, I think
> >it would be great to have it as a configuration directive, because it
> >really is a Good Thing to force programmers to handle errors properly...
> If you are looking for a strictly typed language I'd suggest Java :)

I have used Java to a certain degree (and I think this might be showing
in my way of thinking).  I don't use Java any more; I have moved over to
PHP, both for developing web applications and smaller scripts.  What I
*really* would like to be able to do is to develop larger applications
in PHP.  For this, being able to standardize and even "force" (like in
Java) the code to handle errors is actually a very, very useful
feature.  We've all used badly written programs with few or little error
handling...

> We (as in almost everyone) agree that configuration directives should not
> be added because we want all scripts to run on all PHP enabled servers.

Point taken.  But not everyone is using PHP only on the web.

> >It is true that many people still write imperative (function-based)
> >code.  But that is no argument for not making PHP a really, really good
> >Java-killer.  And, standardized exceptions is really one of the things I
> >find absoutely best in Java.
> We are not in the business of killing Java. We are in the business of being
> the best web programming language.

Like Java.  ;-)

Seriously: the Java people are working hard to make Java be the best web
programming language.  Not *only* a web programming language, of course,
but JSP, servlets and EJB (Enterprise Java Beans, persistent objects)
are striving to provide an excellent web platform.

The only big problem is that it is sooooo much slower than PHP...  and
this is one of the main reasons why I have abandoned Java and JSP for
web development.

> One is a strictly typed compiled language and the other (PHP) a dynamically
> typed scripting language. The reason for PHP's wide adoption is its ease of
> use, especially vs. strongly typed languages such as Java. I want to keep
> this advantage.

I understand that, and I don't want to make PHP harder to use.  I hope
this is not the impression I am giving.  I just want it to be easy to
use for power users *as well* as new users, and friendly when writing
big, enterprise-class applications, applications that benefit greatly
from standardized error handling.

> >Many of the OOP problems of PHP4 have already been fixed
> >in PHP5.  Yet, there is still some room for improvement.
> You might call it improvement and some might call it bloat.

Yes, possibly.  The thing is, I consider OOP to be so much more than
"syntactic sugar".  It is a really helpful paradigm for helping avoiding
many of the common programming mistakes.

> Yes, the important problems with the OOP models have been fixed.
> I don't think we should "improve" PHP until it becomes Java.

:-)

> If that's what you want then java is a URL away.

Thank you, but I have already been down that road and I prefer this one.

> >Just my $0.02.  ;-)
> That was more like $10.00 :)

Yeah, that's why I wrote a smiley.  :-)

--
Wishing you all the best,

Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.capio.com

Andi Gutmans

23 years ago

At 08:08 PM 3/27/2003 +0100, Per Lundberg wrote:

> > >Of course, it should not be done in a way to break backward
> > >compatibility if at all possible.
> > I consider having half of PHP throw errors and the other half as throwing
> > exceptions to break BC.
>
>Even though we are talking about functionalites (type hints) that was
>not even available in previous versions of PHP?

Yep, because I think it's wrong to have a hybrid model and it will confuse
the mainstream of PHP developers.

> > >This is a very bad idea.  One of the points of exceptions is being able
> > >to have a standardized way of handling errors.  I also like the way Java
> > >does it: if you don't catch the exceptions your code could throw, your
> > >code won't even compile.  Now, I am pretty certain that you would not be
> > >happy if I said this would be neat to have in PHP.  :-)  Still, I think
> > >it would be great to have it as a configuration directive, because it
> > >really is a Good Thing to force programmers to handle errors properly...
> > If you are looking for a strictly typed language I'd suggest Java :)
>
>I have used Java to a certain degree (and I think this might be showing
>in my way of thinking).  I don't use Java any more; I have moved over to
>PHP, both for developing web applications and smaller scripts.  What I
>*really* would like to be able to do is to develop larger applications
>in PHP.  For this, being able to standardize and even "force" (like in
>Java) the code to handle errors is actually a very, very useful
>feature.  We've all used badly written programs with few or little error
>handling...

Actually I have done quite a bit of Java development myself and I am not
100% convinced that the fact that it forces you to handle exceptions always
achieves the purpose. I've seen too many Java developers catch exceptions
the following way:
catch (Exception e) {
}

Anyway that's not the issue nor my point :)

> > >It is true that many people still write imperative (function-based)
> > >code.  But that is no argument for not making PHP a really, really good
> > >Java-killer.  And, standardized exceptions is really one of the things I
> > >find absoutely best in Java.
> > We are not in the business of killing Java. We are in the business of
> being
> > the best web programming language.
>
>Like Java.  ;-)
>
>Seriously: the Java people are working hard to make Java be the best web
>programming language.  Not *only* a web programming language, of course,
>but JSP, servlets and EJB (Enterprise Java Beans, persistent objects)
>are striving to provide an excellent web platform.

I somewhat disagree. The Java companies know that EJB isn't suitable for
the mainstream Java web sites. It is mainly useful for real enterprise
applications such as banking systems and it's development overhead is
extremely high and expensive. JSP and servlets are aimed at the web but I
think the reason for PHP being much more popular than Java on the web is
due to its simplicity. The main issue in the web is constant change and
therefore time-to-market is extremely important.

>The only big problem is that it is sooooo much slower than PHP...  and
>this is one of the main reasons why I have abandoned Java and JSP for
>web development.

Slow as in performance or development time? In my opinion the problem is
development time and therefore I think if we move too much towards Java we
will be bitten by the same problem.

> > One is a strictly typed compiled language and the other (PHP) a
> dynamically
> > typed scripting language. The reason for PHP's wide adoption is its
> ease of
> > use, especially vs. strongly typed languages such as Java. I want to keep
> > this advantage.
>
>I understand that, and I don't want to make PHP harder to use.  I hope
>this is not the impression I am giving.  I just want it to be easy to
>use for power users *as well* as new users, and friendly when writing
>big, enterprise-class applications, applications that benefit greatly
>from standardized error handling.

In general, I think the current features in PHP 5 give you a huge amount of
options, including to power users. I don't think adopting most of the
subtle features of Java will make as much of a significant difference but
will likely add bloat and complexity which will end up decreasing PHP
applications's time-to-market. I think the fact that the user land code can
use exceptions is the main advantage.

> > >Many of the OOP problems of PHP4 have already been fixed
> > >in PHP5.  Yet, there is still some room for improvement.
> > You might call it improvement and some might call it bloat.
>
>Yes, possibly.  The thing is, I consider OOP to be so much more than
>"syntactic sugar".  It is a really helpful paradigm for helping avoiding
>many of the common programming mistakes.

Yes, and in my opinion the CVS contains the important features which allow
you to write nice OOP programs. We've solved the real bad issues of OOP in
PHP 4 and have added all of the important features and some on top :)

> > >Just my $0.02.  ;-)
> > That was more like $10.00 :)
>
>Yeah, that's why I wrote a smiley.  :-)

I know :)

Signing off for tonight....
Andi

Per Lundberg

23 years ago

On Thu, 2003-03-27 at 21:42, Andi Gutmans wrote:

I get your points.  I think I'm gonna shut up for now and try using
ZendEngine2 a bit, to see what it's actually like in the Real World.

Thanks for your time.

--
Best regards,

Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.capio.com

Wez Furlong

23 years ago

Please lets have exceptions here, otherwise you will render type-hints
useless (they are intended primarily for OO programmers anyway).

I'm somewhat concerned that we are implementing a lot of the new OO
features in a half-hearted fashion; I understand that there is a balance
to maintain between easy-accessibility and "enterprise" features.

I've mentioned several times now that unhandled exceptions look just
like E_ERRORS to procedural/non-OO programmers; please can we have the
new OO-related features throw exceptions rather than trigger E_ERRORS as
it allows "real" programmers to write more robust code.

--Wez.

On Thu, 27 Mar 2003, Andi Gutmans wrote:

Andi Gutmans

23 years ago

At 09:49 PM 3/27/2003 +0000, Wez Furlong wrote:

>Please lets have exceptions here, otherwise you will render type-hints
>useless (they are intended primarily for OO programmers anyway).

I wouldn't call them useless. It's the same as a script compiler where you
would error out if you don't use the same type except that in our case it'd
be at run-time.

>I'm somewhat concerned that we are implementing a lot of the new OO
>features in a half-hearted fashion; I understand that there is a balance
>to maintain between easy-accessibility and "enterprise" features.

Yes, it is very important to keep the balance. I wouldn't call throwing an
exception if the wrong type is passed as enterprise. We are talking about a
situation which is an error condition in any case. Don't make more of a
deal out of it then what it really is. I don't think we should force people
who are using OOP in a subtle way to have to start handling exceptions
especially as we're keeping all of the rest as E_ERRORS.

>I've mentioned several times now that unhandled exceptions look just
>like E_ERRORS to procedural/non-OO programmers; please can we have the
>new OO-related features throw exceptions rather than trigger E_ERRORS as
>it allows "real" programmers to write more robust code.

Again I disagree. What is a "real" programmer? You have decided that in
real programming wrong types in parameters throw exceptions. This is a very
shallow way of looking at it. I don't think "real" programmer == Java with
all due respect.

Andi

Manuel Lemos

23 years ago

Hello,

I have not had time to look this in detail so I could not reach a
conclusion.

Is the upcoming object model supporting package level member access
retrictions like in Java?

For those that are not aware of what is that, packages are a group of
independent classes (not like nested classes).

The members with package level access restriction can only be accessed
from functions of classes of the same package.

It is something between protected and public. It is less restrictive
than protected level because package members can be accessed from
outside their classes, but is more restrictive than public because they
can only be accessed from functions of classes of the same package
(namespace?!?).

This is not absolutely important but is good for better organization of
packages of several cooperating classes. It is often used when with
packages based on the factory design pattern where there is a central
class that creates objects of other classes. Usually either the factory
and the created object classes provide functions and variables that are
only meant to be used from inside those classes and not outside the package.

--

Regards,
Manuel Lemos

(Marcus Börger)

23 years ago

At 08:43 28.03.2003, Manuel Lemos wrote:

>Hello,
>
>I have not had time to look this in detail so I could not reach a conclusion.
>
>Is the upcoming object model supporting package level member access
>retrictions like in Java?
>
>For those that are not aware of what is that, packages are a group of
>independent classes (not like nested classes).
>
>The members with package level access restriction can only be accessed
>from functions of classes of the same package.

PHP is not JAVA.

Adding Packages and restictions which do not even have a name? Who besides
very expirienced
JAVA programers should understand it?

marcus

Manuel Lemos

23 years ago

Hello,

On 03/28/2003 05:34 AM, Marcus Börger wrote:

>> I have not had time to look this in detail so I could not reach a
>> conclusion.
>>
>> Is the upcoming object model supporting package level member access
>> retrictions like in Java?
>>
>> For those that are not aware of what is that, packages are a group of
>> independent classes (not like nested classes).
>>
>> The members with package level access restriction can only be accessed
>> from functions of classes of the same package.
>
>
>
> PHP is not JAVA.

I was not asking because Java has them but rather because package level
access restrictions are a Good Thing (tm) for better access management
organization between classes that belong to the same package.

Your comment is very curious because after all, many things have been
copied from Java to Zend Engine 2 like: private, protected, public,
final, abstract, interfaces, nested classes.

AFAIK, at least some of these things will make PHP 5 code execute slower
than PHP 4 because they imply making additional checks at run-time,
unlike Java and other languages that only enforce them at compile time.

Maybe I missed the reasoning about adding such features but it sounded
to me like it was meant to make PHP have Java features.

Anyway, I am not suggesting or defending the support of package level
access restriction, I was just asking if it would be made available,
although it is odd that it will support private, protected and public
and not package.

> Adding Packages and restictions which do not even have a name? Who
> besides very expirienced
> JAVA programers should understand it?

Duh?! I do not program in Java and I perfectly understand the point of
package level access restrictions. Maybe you do not understand it
because you are not used to develop packages of classes.

Although I just mentioned Java to help explaining clearly what I meant,
in case you are not aware, I would like to add package is Java default
access restriction mode (public in PHP and private in C++) because it is
very common to ship classes as in packages.

Since Zend Engine 2 supports namespaces, it makes all the sense to
support package access level restrictions as packages and namespaces are
directly related concepts, not to say they the same thing.

--

Regards,
Manuel Lemos

Preston L. Bannister

23 years ago

PHP is not Java - and for good reason.  PHP is a rather nice scripting
language.  PHP scripts are loaded and run for /each and every /request.
In a sense every request starts with a compile.  Clearly to keep the
overhead down you don't want to be compiling in more than is needed to
process the request.

Java is compiled once at development time, and once loaded stays loaded
for all subsequent requests.  With Java you pull in /everything/ during
compilation that might be needed.  Since you are pulling in a /lot/ more
source, you need more structure to keep the code organized and
understandable.  Compiling in more than is needed costs you essentially
nothing.

The payback using PHP is faster iteration during development.  The
payback using Java is greater efficiency - especially for complex
processing.

Note also that given the disparity between network and CPU speeds, and
with a little care in programming, even nominally less efficient PHP
scripts can turn around requests at very respectable rates.

PHP simply should not need as much structure as Java.

BTW, another way to look at the problem is to consider a script as an
object.  The requests and options to which that script responds can be
considered as methods.  Include files can be viewed as inheritance.  In
a very real sense this is object-oriented programming without actually
requiring support for object orientation in the language :).

IMHO - this is enough structure for PHP's role.


Manuel Lemos wrote:

Per Lundberg

23 years ago

On Sat, 2003-03-29 at 02:56, Preston L. Bannister wrote:

> PHP is not Java - and for good reason.  PHP is a rather nice scripting
> language.  PHP scripts are loaded and run for /each and every /request.

Your whole argumentation is based on this assumption, that PHP *only* is
used for writing web scripts.  This is a faulty assumption.  PHP is
already used for writing stand-alone applications (think PHP-GTK and the
CLI SAPI), and this is likely to increase in the future because of the
improvements in the OOP support in PHP 5.

I totally agree a 100% that a quick little web script don't really need
OOP.  But PHP, or rather, the Zend Engine 2, is not limited to only web
scripting.  It can be used for so much more, and that needs to be taken
into consideration when discussing these things.

--
Best regards,

Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.capio.com

Wez Furlong

23 years ago

The point is that we don't raise an E_ERROR when you pass the wrong type
of parameter to any of the other PHP functions.

A "real" programmer is not a Java (*spit!*) programmer; it is someone
that wants to make their code as robust as possible.

Again, I will use the idea of a SOAP server implementation (or any RPC
server); in order to send the correct response to the client, it needs
to be able to catch any runtime error and act appropriately.  Why is
this an issue?  Why doesn't the programmer write code that doesn't use
type-hints?  Well, maybe they won't, but some other person using the
library might, and then they will wonder a). Why it doesn't work?  b).
What is the point of having a type hint anyway?

Using E_ERROR also prohibits using CLI or embedded PHP in a long-lived
application.  I know that PHP is designed primarily for use in a web
server, but it seems incredibly short sighted to design new features
that make using CLI or embed impossible.

--Wez.

On Fri, 28 Mar 2003, Andi Gutmans wrote:

Per Lundberg

23 years ago

On Fri, 2003-03-28 at 11:04, Wez Furlong wrote:

> Using E_ERROR also prohibits using CLI or embedded PHP in a long-lived
> application.  I know that PHP is designed primarily for use in a web
> server, but it seems incredibly short sighted to design new features
> that make using CLI or embed impossible.

100% agreed.

--
Best regards,

Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.capio.com

Sterling Hughes

23 years ago

This again gets to my nit regarding runtime features in a dynamically
typed language.  One of the reasons type checking in C, C++, Java is a
good thing is its done at compile time, not runtime.  Type mistakes,
especially in large libraries can be pesky things, often hard to check
for (and often harmless).  A PHP script should not automagically bail
out on a type mismatch.   I think that if this called in a try {} loop
an exception should be thrown (will this be achieved by George's patch?)

-Sterling

On Thu, 2003-03-27 at 21:08, Andi Gutmans wrote:

> At 09:49 PM 3/27/2003 +0000, Wez Furlong wrote:
> >Please lets have exceptions here, otherwise you will render type-hints
> >useless (they are intended primarily for OO programmers anyway).
>
> I wouldn't call them useless. It's the same as a script compiler where you
> would error out if you don't use the same type except that in our case it'd
> be at run-time.
>
>
> >I'm somewhat concerned that we are implementing a lot of the new OO
> >features in a half-hearted fashion; I understand that there is a balance
> >to maintain between easy-accessibility and "enterprise" features.
>
> Yes, it is very important to keep the balance. I wouldn't call throwing an
> exception if the wrong type is passed as enterprise. We are talking about a
> situation which is an error condition in any case. Don't make more of a
> deal out of it then what it really is. I don't think we should force people
> who are using OOP in a subtle way to have to start handling exceptions
> especially as we're keeping all of the rest as E_ERRORS.
>
>
> >I've mentioned several times now that unhandled exceptions look just
> >like E_ERRORS to procedural/non-OO programmers; please can we have the
> >new OO-related features throw exceptions rather than trigger E_ERRORS as
> >it allows "real" programmers to write more robust code.
>
> Again I disagree. What is a "real" programmer? You have decided that in
> real programming wrong types in parameters throw exceptions. This is a very
> shallow way of looking at it. I don't think "real" programmer == Java with
> all due respect.
>
> Andi

--
"First they ignore you, then they laugh at you,
then they fight you, then you win."
- Gandhi

Stig S. Bakken

23 years ago

Amen to that.  Type checking at compile time and run time are _very_
different things.

Just to voice my opinion on this type hint thingie: IMHO it's useless to
have a type hinting feature that has no way of catching the wrong type
passed.  If it may be caught, great let's do that, if not let's nuke
type hints.  Then we move on :-)

- Stig

On Fri, 2003-03-28 at 14:42, Sterling Hughes wrote:

Andi Gutmans

23 years ago

We won't support this. (btw it's the default modifier in Java if you don't
write anything else).

Andi

At 04:43 AM 3/28/2003 -0300, Manuel Lemos wrote:

Manuel Lemos

23 years ago

Hello,

On 03/28/2003 10:57 AM, Andi Gutmans wrote:

> We won't support this. (btw it's the default modifier in Java if you
> don't write anything else).

I am not defending or suggesting that you support it, I am just asking
if you will. BTW, what is the reasoning for supporting private,
protected and public, but not package (namespace?!)?

--

Regards,
Manuel Lemos

Andi Gutmans

23 years ago

At 10:29 PM 3/28/2003 -0300, Manuel Lemos wrote:

>Hello,
>
>On 03/28/2003 10:57 AM, Andi Gutmans wrote:
>>We won't support this. (btw it's the default modifier in Java if you
>>don't write anything else).
>
>I am not defending or suggesting that you support it, I am just asking if
>you will. BTW, what is the reasoning for supporting private, protected and
>public, but not package (namespace?!)?

private/protected/public are topics which most people who have used OOP in
the past understand well. Package level access tend to be much more
confusing and aren't as common. That's why I see a difference.

Andi

Manuel Lemos

23 years ago

Hello,

On 03/29/2003 04:36 AM, Andi Gutmans wrote:

>>> We won't support this. (btw it's the default modifier in Java if you
>>> don't write anything else).
>>
>>
>> I am not defending or suggesting that you support it, I am just asking
>> if you will. BTW, what is the reasoning for supporting private,
>> protected and public, but not package (namespace?!)?
>
>
> private/protected/public are topics which most people who have used OOP
> in the past understand well. Package level access tend to be much more
> confusing and aren't as common. That's why I see a difference.

I don't see what is so confusing in only allow to access the members of
a class from another true class that belongs to the same package.

Anyway, your reasoning is interesting because while you justify not
adopting a protection level that is useful to people that develop
packages with several classes (think of many of the packages in PEAR if
not anything else), you add things that seem much more confusing and
less useful like nested classes and interfaces!?!


-

Regards,
Manuel Lemos

Derick Rethans

23 years ago

On Sat, 29 Mar 2003, Manuel Lemos wrote:

> ... you add things that seem much more confusing and
> less useful like nested classes and interfaces!?!

There are no nested classes in PHP 5

Derick

--
"my other box is your windows PC"
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals       http://php-mag.net/
-------------------------------------------------------------------------

Manuel Lemos

23 years ago

Hello,

On 03/29/2003 08:46 AM, Derick Rethans wrote:

>>... you add things that seem much more confusing and
>>less useful like nested classes and interfaces!?!
>
>
> There are no nested classes in PHP 5

Maybe I confused it with nested namespaces (packages) which is even more
confusing to whoever uses classes with them.

http://talks.php.net/show/php5intro/4

--

Regards,
Manuel Lemos

Sebastian Bergmann

23 years ago

Manuel Lemos wrote:

> Maybe I confused it with nested namespaces (packages) which is even
> more confusing to whoever uses classes with them.

Namespaces aren't nested, either.

--
Sebastian Bergmann
http://sebastian-bergmann.de/                 http://phpOpenTracker.de/

Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

Manuel Lemos

23 years ago

Hello,

On 03/29/2003 09:48 AM, Sebastian Bergmann wrote:

>>Maybe I confused it with nested namespaces (packages) which is even
>>more confusing to whoever uses classes with them.
>
>
>   Namespaces aren't nested, either.

Go and discuss that with Sterling Hughes as he was the one that wrote
this presentation:

http://talks.php.net/show/php5intro/4

Maybe that is why the output of the example in that page is a parse
error! ;-)

--

Regards,
Manuel Lemos

Andi Gutmans

23 years ago

At 10:04 AM 3/28/2003 +0000, Wez Furlong wrote:

>The point is that we don't raise an E_ERROR when you pass the wrong type
>of parameter to any of the other PHP functions.

Really? I think that some functions which use resources do error out if you
pass a wrong type (although I'm not quite sure), but there's no reason it
shouldn't.

>A "real" programmer is not a Java (*spit!*) programmer; it is someone
>that wants to make their code as robust as possible.
>
>Again, I will use the idea of a SOAP server implementation (or any RPC
>server); in order to send the correct response to the client, it needs
>to be able to catch any runtime error and act appropriately.  Why is
>this an issue?  Why doesn't the programmer write code that doesn't use
>type-hints?  Well, maybe they won't, but some other person using the
>library might, and then they will wonder a). Why it doesn't work?  b).
>What is the point of having a type hint anyway?

The point of type-hints is to be able to catch errors in your code quickly
and not having to write checks, the point isn't to catch problems in your
code at run-time. And as I said before, if it doesn't suite you then don't
use type-hints and use instanceof like you would have done 2 weeks ago.
It's not a disaster so don't make it sound like one. So much has changed in
the past two weeks? If you need to catch errors because you are writing
something generic such as SOAP (which most of the PHP community doesn't do)
then go ahead and do the instanceof's you need to do.

>Using E_ERROR also prohibits using CLI or embedded PHP in a long-lived
>application.  I know that PHP is designed primarily for use in a web
>server, but it seems incredibly short sighted to design new features
>that make using CLI or embed impossible.

Exceptions have a potential of leaking memory. I have mentioned in the past
that I wouldn't base my applications logic on exceptions but only use it in
error conditions to clean-up and/or give a nice message. You are talking
about using it as part of your application logic.
You are convincing me more and more not to throw an exception with type hints.

Andi

Derick Rethans

23 years ago

On Fri, 28 Mar 2003, Andi Gutmans wrote:

> At 10:04 AM 3/28/2003 +0000, Wez Furlong wrote:
> >The point is that we don't raise an E_ERROR when you pass the wrong type
> >of parameter to any of the other PHP functions.
>
> Really? I think that some functions which use resources do error out if you
> pass a wrong type (although I'm not quite sure), but there's no reason it
> shouldn't.

None should, the goal was that extensions should at max raise E_WARNING
if there is no real need to abort the script. AFAIK this was implemented
almost everywhere.

Derick

--
"my other box is your windows PC"
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals       http://php-mag.net/
-------------------------------------------------------------------------

Wez Furlong

23 years ago

On Fri, 28 Mar 2003, Andi Gutmans wrote:

> The point of type-hints is to be able to catch errors in your code
> quickly and not having to write checks, the point isn't to catch
> problems in your code at run-time. And as I said before, if it doesn't
> suite you then don't use type-hints and use instanceof like you would
> have done 2 weeks ago.  It's not a disaster so don't make it sound
> like one. So much has changed in the past two weeks? If you need to
> catch errors because you are writing something generic such as SOAP
> (which most of the PHP community doesn't do) then go ahead and do the
> instanceof's you need to do.

The point is that the SOAP (or whatever) library will be interfacing
with code written by others.  If those other people use type hints and
it blows up with an E_ERROR, we don't have a nice way to handle this
error and continue serving.

This *is* a disaster, because we are introducing a feature that appears
to be quite nice at first glance, but causes portability issues with
peoples scripts; for instance; PEAR scripts that use type hints will
immediately be incompatible with a larger application framework.
Therefore, PEAR should not use type hints if it wants to remain
portable.

The same applies to all script libraries.

> Exceptions have a potential of leaking memory. I have mentioned in the
> past that I wouldn't base my applications logic on exceptions but only
> use it in error conditions to clean-up and/or give a nice message. You
> are talking about using it as part of your application logic.

What is the point of structured exception handling if you are not
supposed to use it to code the logic to handle run time errors?

> You are convincing me more and more not to throw an exception with
> type hints.

And you are convincing me more and more that the OOP and error handling
model in PHP5 will continue to be half-assed for a long time to come :/

What is *so* wrong with throwing an exception from type hints?  It will
still cause the script to bail out if the exception is not caught (which
will keep you and the novice programmers happy), and it allows more
advanced programmers to apply PHP in more and more advanced ways.

--Wez.

Brian Moon

23 years ago

| The point is that the SOAP (or whatever) library will be interfacing
| with code written by others.  If those other people use type hints and
| it blows up with an E_ERROR, we don't have a nice way to handle this
| error and continue serving.
|
| This *is* a disaster, because we are introducing a feature that appears
| to be quite nice at first glance, but causes portability issues with
| peoples scripts; for instance; PEAR scripts that use type hints will
| immediately be incompatible with a larger application framework.
| Therefore, PEAR should not use type hints if it wants to remain
| portable.

I am no "novice" programmer, but I don't get where you are going here.  How
is there a portability problem?  You are either calling the method with the
right paramaters or you aren't.  What am I missing?

Brian.
dealnews.com

Stig S. Bakken

23 years ago

On Fri, 2003-03-28 at 16:36, Brian Moon wrote:

> | The point is that the SOAP (or whatever) library will be interfacing
> | with code written by others.  If those other people use type hints and
> | it blows up with an E_ERROR, we don't have a nice way to handle this
> | error and continue serving.
> |
> | This *is* a disaster, because we are introducing a feature that appears
> | to be quite nice at first glance, but causes portability issues with
> | peoples scripts; for instance; PEAR scripts that use type hints will
> | immediately be incompatible with a larger application framework.
> | Therefore, PEAR should not use type hints if it wants to remain
> | portable.
>
> I am no "novice" programmer, but I don't get where you are going here.  How
> is there a portability problem?  You are either calling the method with the
> right paramaters or you aren't.  What am I missing?

You may be passing an object to a function that again calls a piece of
library code using type hints (but you don't have to know that).  If
your object is of the wrong type, PHP dies.  PEAR packages follow a
strict "stay alive" policy, so this would not be acceptable for a PEAR
package.  In other words, PEAR can not use type hints if they may cause
PHP to exit.

- Stig

Andi Gutmans

23 years ago

At 03:00 PM 3/28/2003 +0000, Wez Furlong wrote:

>On Fri, 28 Mar 2003, Andi Gutmans wrote:
>
> > The point of type-hints is to be able to catch errors in your code
> > quickly and not having to write checks, the point isn't to catch
> > problems in your code at run-time. And as I said before, if it doesn't
> > suite you then don't use type-hints and use instanceof like you would
> > have done 2 weeks ago.  It's not a disaster so don't make it sound
> > like one. So much has changed in the past two weeks? If you need to
> > catch errors because you are writing something generic such as SOAP
> > (which most of the PHP community doesn't do) then go ahead and do the
> > instanceof's you need to do.
>
>The point is that the SOAP (or whatever) library will be interfacing
>with code written by others.  If those other people use type hints and
>it blows up with an E_ERROR, we don't have a nice way to handle this
>error and continue serving.

If those people decided to use type hints then they are getting what they
expected, no?

>This *is* a disaster, because we are introducing a feature that appears
>to be quite nice at first glance, but causes portability issues with
>peoples scripts; for instance; PEAR scripts that use type hints will
>immediately be incompatible with a larger application framework.
>Therefore, PEAR should not use type hints if it wants to remain
>portable.
>
>The same applies to all script libraries.

I guess I'm completely missing your point. Why will PEAR scripts using type
hints be incompatible with a larger application framework? You forget that
passing the wrong type to a PEAR function *is* an error. How come you
suddenly don't want any errors? Do you want people to be able to do as much
damage as they want?

> > Exceptions have a potential of leaking memory. I have mentioned in the
> > past that I wouldn't base my applications logic on exceptions but only
> > use it in error conditions to clean-up and/or give a nice message. You
> > are talking about using it as part of your application logic.
>
>What is the point of structured exception handling if you are not
>supposed to use it to code the logic to handle run time errors?

You're supposed to use it to handle run-time errors but not base your
application's logic on throwing exceptions, i.e., on purpose not check what
types you are sending to a function because you prefer to handle the
exception. In a long lived environment this will be a problem because
you'll end up having scripts with a large amount of exceptions.

> > You are convincing me more and more not to throw an exception with
> > type hints.
>
>And you are convincing me more and more that the OOP and error handling
>model in PHP5 will continue to be half-assed for a long time to come :/

I'm sorry to hear that you consider the OOP support in PHP 5 to be half
assed. Personally I think people like you who are trying to pervert PHP
into Java are just going to cause damage to PHP. The current tree has very
good functionality which will be an incredibly big step forward for people
wanting to develop OOP with PHP.

>What is *so* wrong with throwing an exception from type hints?  It will
>still cause the script to bail out if the exception is not caught (which
>will keep you and the novice programmers happy), and it allows more
>advanced programmers to apply PHP in more and more advanced ways.

It's not *so* wrong but I think you guys are exaggerating with the tragic
"this is terrible" sound you have about each little relatively
non-signifcant feature which will just end up bloating PHP, make it more
complex, and in the end will make it into Java. I don't want to abandon the
existing user base. Again, why work hard if Java already exists?

Andi

Wez Furlong

23 years ago

On Fri, 28 Mar 2003, Andi Gutmans wrote:

> I guess I'm completely missing your point. Why will PEAR scripts using
> type hints be incompatible with a larger application framework? You
> forget that passing the wrong type to a PEAR function *is* an error.
> How come you suddenly don't want any errors? Do you want people to be
> able to do as much damage as they want?

A writes an application framework as part of their commercial product.
B writes a generic class and publishes it in PEAR (using type hints).
C purchases the app from A and extends it using the class from B.

There is nothing that A can do to prevent or catch the E_ERROR from the
typehint.

We can use function_exists() to prevent errors when calling functions,
but there is no is_parameter_of_correct_type() function to guard against
this problem.  The reflection API will help, but it still makes things
suck more than is strictly needed.

> You're supposed to use it to handle run-time errors but not base your
> application's logic on throwing exceptions, i.e., on purpose not check
> what types you are sending to a function because you prefer to handle
> the exception. In a long lived environment this will be a problem
> because you'll end up having scripts with a large amount of
> exceptions.

A's code knows nothing about B or C's code; its intention is just to
catch all errors, report the problem and try to keep running.

If exceptions leak memory, that implies that their implementation is
flawed; there should be no reason that they leak (based on my
understanding of the ZE, which is not quite so good as yours ;-) its
just an opcode executed by the engine; any locally scoped zvals should
be dtor'ed when the stack unwinds.

> I'm sorry to hear that you consider the OOP support in PHP 5 to be
> half assed. Personally I think people like you who are trying to
> pervert PHP into Java are just going to cause damage to PHP. The
> current tree has very good functionality which will be an incredibly
> big step forward for people wanting to develop OOP with PHP.

I don't like Java; my opinions on this matter have nothing to do with
Java.  I've some plans for some nice big applications that I can
*almost* write using PHP.  The limiting factor has primarily been the
not-so-good OOP support in PHP4; things have been looking good to go
with PHP5, but the number of the new OOP features that raise E_ERRORS is
making it difficult to write code that can intelligently deal with the
errors.

I'm not neccessarily talking about long-lived applications, but
applications where there is a large amount of complex shutdown/recovery
code to execute in the face of an error.

>
> >What is *so* wrong with throwing an exception from type hints?  It
> >will still cause the script to bail out if the exception is not
> >caught (which will keep you and the novice programmers happy), and it
> >allows more advanced programmers to apply PHP in more and more
> >advanced ways.
>
> It's not *so* wrong but I think you guys are exaggerating with the
> tragic "this is terrible" sound you have about each little relatively
> non-signifcant feature which will just end up bloating PHP, make it
> more complex, and in the end will make it into Java. I don't want to
> abandon the existing user base.

I don't see how having type-hints throw exceptions is abandoning an
existing userbase; it's a new feature anyway.

> Again, why work hard if Java already exists?

Because Java sucks and because PHP can be so much better :)

One of the reasons that I like PHP is that it is loose enough that you
can focus on writing code rather than battling with over the top
syntax/type restrictions (Java), or with the tedious string manipulation
(C).

I *like* PHP; it tries to keep running in the face of non-fatal errors.

I don't like E_ERRORS when there is no real reason to bail out.
As I've already said, non of the other PHP functions trigger E_ERROR
when the parameters are incorrect; it's just an E_WARNING and a NULL
value return.

Implementing these new OOP features and having them E_ERROR is
tremendously unhelpful (the PPP stuff also suffers from the same
problem).

I don't want PHP to be a Java clone any more than you do, but why code
these great new features with such limitations from the start?

Surely this is just a one-line change anyway (just substitute zend_error
for the exception raising macro)?

--Wez.

Brian Moon

23 years ago

| I don't like E_ERRORS when there is no real reason to bail out.
| As I've already said, non of the other PHP functions trigger E_ERROR
| when the parameters are incorrect; it's just an E_WARNING and a NULL
| value return.

This is a good point.  foreach for example issues a warning.  So do all the
array function in PHP.  My original RFC on this matter (that had nothing to
do with classes) said to issue a fatal error, but, in retrospect, prehaps it
should be a warning.  And include arrays. ;)

Brian.
dealnews.com

Stig S. Bakken

23 years ago

On Fri, 2003-03-28 at 15:03, Andi Gutmans wrote:

>
> Exceptions have a potential of leaking memory. I have mentioned in the past
> that I wouldn't base my applications logic on exceptions but only use it in
> error conditions to clean-up and/or give a nice message. You are talking
> about using it as part of your application logic.

If I can't use exceptions for application logic, why should I bother
with using exceptions at all when there is trigger_error() and die()?

Being able to control the flow of my code (that is application logic to
me) is my main motivation for using exceptions in the first place.

With all due respect Andi, I think adding exceptions to PHP and at the
same time discouraging programmers to not use them to control program
flow is a Bad Idea[tm].

- Stig

Zeev Suraski

23 years ago

At 03:22 03/04/2003, Stig S. Bakken wrote:

>On Fri, 2003-03-28 at 15:03, Andi Gutmans wrote:
> >
> > Exceptions have a potential of leaking memory. I have mentioned in the
> past
> > that I wouldn't base my applications logic on exceptions but only use
> it in
> > error conditions to clean-up and/or give a nice message. You are talking
> > about using it as part of your application logic.
>
>If I can't use exceptions for application logic, why should I bother
>with using exceptions at all when there is trigger_error() and die()?

If you use exceptions for application logic, then you're writing bad code,
regardless of the language!  It's one of the cases of clear
over-design.  Exception handling provides an OO way of handling errors,
that is more fine-grained than set_error_handler() and
trigger_error().  Nothing more, nothing less.

Zeev

Andi Gutmans

23 years ago

At 08:42 AM 3/28/2003 -0500, Sterling Hughes wrote:

>This again gets to my nit regarding runtime features in a dynamically
>typed language.  One of the reasons type checking in C, C++, Java is a
>good thing is its done at compile time, not runtime.  Type mistakes,
>especially in large libraries can be pesky things, often hard to check
>for (and often harmless).  A PHP script should not automagically bail
>out on a type mismatch.   I think that if this called in a try {} loop
>an exception should be thrown (will this be achieved by George's patch?)

You just said that the fact that C, C++ and Java make it a fatal error at
compile-time is a good thing.
And I strongly disagree that a type mistake is often harmless if the author
specifically specified the type he wants. If you think it's harmless then
don't use type hints.
Guys, I'm starting to get rundown by this arguing. I am extremely worried
about the current trend of wanting PHP to support everything Java supports.
I think this is the wrong direction for PHP and I think it doesn't reflect
the needs of the majority of PHP users but the academic interest of purists
on this list. You are loosing sight of where PHP comes from and what the
majority of our user base is.
I seriously mean it, that if you are looking for a language with all of the
features of Java then you can just go to java.sun.com. I hear that .jsp is
really good :)

Andi

Sterling Hughes

23 years ago

On Fri, 2003-03-28 at 09:15, Andi Gutmans wrote:

> At 08:42 AM 3/28/2003 -0500, Sterling Hughes wrote:
> >This again gets to my nit regarding runtime features in a dynamically
> >typed language.  One of the reasons type checking in C, C++, Java is a
> >good thing is its done at compile time, not runtime.  Type mistakes,
> >especially in large libraries can be pesky things, often hard to check
> >for (and often harmless).  A PHP script should not automagically bail
> >out on a type mismatch.   I think that if this called in a try {} loop
> >an exception should be thrown (will this be achieved by George's patch?)
>
> You just said that the fact that C, C++ and Java make it a fatal error at
> compile-time is a good thing.
> And I strongly disagree that a type mistake is often harmless if the author
> specifically specified the type he wants. If you think it's harmless then
> don't use type hints.
> Guys, I'm starting to get rundown by this arguing. I am extremely worried
> about the current trend of wanting PHP to support everything Java supports.
> I think this is the wrong direction for PHP and I think it doesn't reflect
> the needs of the majority of PHP users but the academic interest of purists
> on this list. You are loosing sight of where PHP comes from and what the
> majority of our user base is.
> I seriously mean it, that if you are looking for a language with all of the
> features of Java then you can just go to java.sun.com. I hear that .jsp is
> really good :)
>

Pah, we all know the future is psp
(http://www.edwardbear.org/mod_psp-0.3.tar.gz ;-)

Just to be clear: I'd be happier without type hinting then type hinting
throwing an E_ERROR (a E_WARNING would also make me happy).

The problem I have is the 1% of the time where a type mismatch doesn't
get caught, running normal code on a production site, and it causes a
bailout.  I can imagine that's going to cause quite a few errors
(display_errors off, hard to reproduce bug).

-Sterling

--
"Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it."
- Richard Feynman

Derick Rethans

23 years ago

On Fri, 28 Mar 2003, Sterling Hughes wrote:

> Pah, we all know the future is psp
> (http://www.edwardbear.org/mod_psp-0.3.tar.gz ;-)
>
> Just to be clear: I'd be happier without type hinting then type hinting
> throwing an E_ERROR (a E_WARNING would also make me happy).

I agree 100% here.

Derick

--
"my other box is your windows PC"
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals       http://php-mag.net/
-------------------------------------------------------------------------

Stanislav Malyshev

23 years ago

DR>> > Just to be clear: I'd be happier without type hinting then type hinting
DR>> > throwing an E_ERROR (a E_WARNING would also make me happy).
DR>>
DR>> I agree 100% here.

If so, what on the Earth prevents you from not using type hinting and
being happy? Or you want to say you would be better without _others_ using
type hinting than _others_ using it with E_ERROR? That's one strange point
of view then :)

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.109

Wez Furlong

23 years ago

Type hinting, if it causes a bail-out, renders the scripts non-portable
to (the growing number of) applications that intend to stick around for
longer than a short web-request.

So yes, I'd be happier without anyone having type hints than having type
hints E_ERROR.  (which is inconsistent with all of the other parameter
checking macros and functions already in use in PHP).

--Wez.

On Sun, 30 Mar 2003, Stanislav Malyshev wrote:

Stanislav Malyshev

23 years ago

WF>> Type hinting, if it causes a bail-out, renders the scripts
WF>> non-portable to (the growing number of) applications that intend to
WF>> stick around for longer than a short web-request.

Well, I do not completely understand how it is "non-portable". If the
script calls "hinted" function with wrong parameters, it is a fatal error
- I see no sane (meaning, safe not for your particular application, but
for all of them) way to continue from here except for saying the user
"Well, doh!" and exiting. That's like calling function with wrong name -
how can you continue from there and expect it works?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.109

Wez Furlong

23 years ago

You can use function_exists() to avoid a fatal error, but there is no
equivalent function_parameters_are_ok() API to avoid a miserable death
in the situations that I have already mentioned.

Why not just be consistent with all the other parameter checks and raise
an E_WARNING and RETURN_NULL when the parameters are incorrect?
I don't see what is so special about hinted parameters that they have to
bail out the engine, while the built-in (and extension) functions will
happily return NULL and continue execution.

--Wez.

On Mon, 31 Mar 2003, Stanislav Malyshev wrote:

Zeev Suraski

23 years ago

At 15:55 31/03/2003, Wez Furlong wrote:

>You can use function_exists() to avoid a fatal error, but there is no
>equivalent function_parameters_are_ok() API to avoid a miserable death
>in the situations that I have already mentioned.
>
>Why not just be consistent with all the other parameter checks and raise
>an E_WARNING and RETURN_NULL when the parameters are incorrect?
>I don't see what is so special about hinted parameters that they have to
>bail out the engine, while the built-in (and extension) functions will
>happily return NULL and continue execution.

I see a huge difference.  First off, most functions don't return NULL or
even bail out at all, they just convert their argument as necessary and try
to make do.  Secondly, I see a big difference between built-in functions
and userland functions.  With userland functions, I think there's a very
high WTF factor for them returning without actually running their code.  I
don't think that this WTF factor exists for built-in functions, as they are
perceived as black-boxes.  Returning NULL works well in case your function
has a meaningful return value, such a result set, SQL link, a string or
what not.  It's not that useful when your function is returning nothing, or
when it has a return value that's not likely to be checked.

Zeev

(Marcus Börger)

23 years ago

At 14:55 31.03.2003, Wez Furlong wrote:

>You can use function_exists() to avoid a fatal error, but there is no
>equivalent function_parameters_are_ok() API to avoid a miserable death
>in the situations that I have already mentioned.
>
>Why not just be consistent with all the other parameter checks and raise
>an E_WARNING and RETURN_NULL when the parameters are incorrect?
>I don't see what is so special about hinted parameters that they have to
>bail out the engine, while the built-in (and extension) functions will
>happily return NULL and continue execution.

We are NOT consistent. Some functions return NULL, some return false
and most functions do not even document what they do. And there are
functions that return NULL and false depending on the type of error.

marcus

Harald Radi

23 years ago

> Well, I do not completely understand how it is "non-portable". If the
> script calls "hinted" function with wrong parameters, it is a
> fatal error
> - I see no sane (meaning, safe not for your particular
> application, but
> for all of them) way to continue from here except for saying the user
> "Well, doh!" and exiting. That's like calling function with

"Well, doh! Reenter the frickin' parameter."

harald

(Marcus Börger)

23 years ago

At 14:03 31.03.2003, Stanislav Malyshev wrote:

>WF>> Type hinting, if it causes a bail-out, renders the scripts
>WF>> non-portable to (the growing number of) applications that intend to
>WF>> stick around for longer than a short web-request.
>
>Well, I do not completely understand how it is "non-portable". If the
>script calls "hinted" function with wrong parameters, it is a fatal error
>- I see no sane (meaning, safe not for your particular application, but
>for all of them) way to continue from here except for saying the user
>"Well, doh!" and exiting. That's like calling function with wrong name -
>how can you continue from there and expect it works?

Exceptions are exceptions (try to think about the meaning of the spoken
word). And the sense of exception handlers is to take care of such
exceptions. Now calling a non existing function or calling it with the
wrong parameters is an exception. The first is the exception that the
necessary function is not present and the second is the exception that
an illegal parameter was passed.

The first typically happens when some dynamic loading failed. As
someone writing safe and robust code you should take care of this.
And in some cases you might be able to do a fallback rather then
the only current possibility to pull out a nice error message.

The second typically happens in when in a portable application
something went wrong. In those cases there is only some little
part not working and often this can be more or less ignored if taken
care of in an exception handler.

Having exceptions *only* to throw user defined exceptions stands in
total contrast to what they are about. If so the less expirienced
programmer is lead to use his own exceptions. And as someone already
said (was it Zeev) typically exceptions are to expensive.

regards
marcus

Andi Gutmans

23 years ago

At 03:19 PM 3/28/2003 +0100, Derick Rethans wrote:

>On Fri, 28 Mar 2003, Sterling Hughes wrote:
>
> > Pah, we all know the future is psp
> > (http://www.edwardbear.org/mod_psp-0.3.tar.gz ;-)
> >
> > Just to be clear: I'd be happier without type hinting then type hinting
> > throwing an E_ERROR (a E_WARNING would also make me happy).
>
>I agree 100% here.

OK so maybe we should go ahead and nuke it and save us the argument. I can
live without it. It's just syntactic sugar to save developers a few keystrokes.

Andi

Sebastian Bergmann

23 years ago

Andi Gutmans wrote:

> OK so maybe we should go ahead and nuke it and save us the argument.

Please, no.

--
Sebastian Bergmann
http://sebastian-bergmann.de/                 http://phpOpenTracker.de/

Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

Andi Gutmans

23 years ago

At 03:56 PM 3/28/2003 +0100, Sebastian Bergmann wrote:

>Andi Gutmans wrote:
> > OK so maybe we should go ahead and nuke it and save us the argument.
>
>   Please, no.

The main problem is that people are getting carried away and instead of
looking at the big step forward the OOP model has done since PHP 4 and how
useful it will be, they are thinking of how much is left to change PHP into
Java. i.e. it is going to be a never-ending story until PHP successfully
compiles Java code (from now on I'll use the term deltaJava as the delta
between Java and PHP).
Therefore, I prefer nuking what I consider a cute nice-to-have feature
which I don't consider critical, instead of making the extra step and
waiting for the next complaint found about a feature which exists in deltaJava.

Andi

Sterling Hughes

23 years ago

On Fri, 2003-03-28 at 10:52, Andi Gutmans wrote:

> At 03:56 PM 3/28/2003 +0100, Sebastian Bergmann wrote:
> >Andi Gutmans wrote:
> > > OK so maybe we should go ahead and nuke it and save us the argument.
> >
> >   Please, no.
>
> The main problem is that people are getting carried away and instead of
> looking at the big step forward the OOP model has done since PHP 4 and how
> useful it will be, they are thinking of how much is left to change PHP into
> Java. i.e. it is going to be a never-ending story until PHP successfully
> compiles Java code (from now on I'll use the term deltaJava as the delta
> between Java and PHP).
> Therefore, I prefer nuking what I consider a cute nice-to-have feature
> which I don't consider critical, instead of making the extra step and
> waiting for the next complaint found about a feature which exists in deltaJava.
>

I personally agree.  I think that type-hints are nice, but will
ultimately be too much a pita if the error can not be recovered from.

One thing, just a wild, and half-baked idea, but why not have a
E_MAKE_US_ALL_HAPPY, error level, that doesn't call the current function
(because types are wrong, but doesn't halt script execution either.

My concern with typehints is two-fold:

1) It forces pointless type-conformity in the majority of PHP code.  It
does have some good uses (SOAP for example), but I fear it will be
overused by OO-zealots, who still haven't gotten that PHP isn't Java -
and that's a *GOOD* thing.

2) It throws an E_ERROR.  If this is going to be a runtime feature, I
want to have someway to recover from it.   Perhaps it can limit the
function from being called, but not kill script execution?

-Sterling

--
"I can't give you a brain, so I'll give you a diploma"
- The Great Oz, The Wizard of Oz

Andi Gutmans

23 years ago

At 10:57 AM 3/28/2003 -0500, Sterling Hughes wrote:

>On Fri, 2003-03-28 at 10:52, Andi Gutmans wrote:
> > At 03:56 PM 3/28/2003 +0100, Sebastian Bergmann wrote:
> > >Andi Gutmans wrote:
> > > > OK so maybe we should go ahead and nuke it and save us the argument.
> > >
> > >   Please, no.
> >
> > The main problem is that people are getting carried away and instead of
> > looking at the big step forward the OOP model has done since PHP 4 and how
> > useful it will be, they are thinking of how much is left to change PHP
> into
> > Java. i.e. it is going to be a never-ending story until PHP successfully
> > compiles Java code (from now on I'll use the term deltaJava as the delta
> > between Java and PHP).
> > Therefore, I prefer nuking what I consider a cute nice-to-have feature
> > which I don't consider critical, instead of making the extra step and
> > waiting for the next complaint found about a feature which exists in
> deltaJava.
> >
>
>I personally agree.  I think that type-hints are nice, but will
>ultimately be too much a pita if the error can not be recovered from.
>
>One thing, just a wild, and half-baked idea, but why not have a
>E_MAKE_US_ALL_HAPPY, error level, that doesn't call the current function
>(because types are wrong, but doesn't halt script execution either.
>
>My concern with typehints is two-fold:
>
>1) It forces pointless type-conformity in the majority of PHP code.  It
>does have some good uses (SOAP for example), but I fear it will be
>overused by OO-zealots, who still haven't gotten that PHP isn't Java -
>and that's a *GOOD* thing.
>
>2) It throws an E_ERROR.  If this is going to be a runtime feature, I
>want to have someway to recover from it.   Perhaps it can limit the
>function from being called, but not kill script execution?

Changing PHP's behavior with a different error level is only a tad bit
better than adding an INI directive. In general I'd like the core language
to behave the same no matter what error level or INI settings.
I say nuke type-hints and let the purists use instanceof.

Andi

Sebastian Bergmann

23 years ago

Andi Gutmans wrote:

> I say nuke type-hints and let the purists use instanceof.

I know that Type Hints are only syntax sugar for instanceof, but I'd
still rather have them, than not.

Any why is not possible - this may have been discussed before, not
sure - to throw an exception when the types are wrong?

--
Sebastian Bergmann
http://sebastian-bergmann.de/                 http://phpOpenTracker.de/

Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

Steph

23 years ago

> Changing PHP's behavior with a different error level is only a tad bit
> better than adding an INI directive. In general I'd like the core

language

> to behave the same no matter what error level or INI settings.
> I say nuke type-hints and let the purists use instanceof.
>
> Andi
>

Speaking as one who battles with PHP rather than with C most of the
time, I'm with Andi here.  People who are likely to use OOP to any
extent are also going to be people who can work around typing issues.
The rest of us are going to be left staring pitifully at our broken code
for hours on end :-\

Andi Gutmans

23 years ago

At 08:59 AM 3/28/2003 -0500, Sterling Hughes wrote:

>Pah, we all know the future is psp
>(http://www.edwardbear.org/mod_psp-0.3.tar.gz ;-)

psp sucks badly :P

>Just to be clear: I'd be happier without type hinting then type hinting
>throwing an E_ERROR (a E_WARNING would also make me happy).
>
>The problem I have is the 1% of the time where a type mismatch doesn't
>get caught, running normal code on a production site, and it causes a
>bailout.  I can imagine that's going to cause quite a few errors
>(display_errors off, hard to reproduce bug).

You mean that a function which is supposed to receive an object and calls
methods on that objects/manipulates that object and etc. shouldn't lead to
a fatal error? I think you're exaggerating big time. I think this is a case
where you want your script to fail and you can use the error handler to
create a more user friendly error page.

Andi

Zeev Suraski

23 years ago

At 11:49 28/03/2003, Wez Furlong wrote:

>Please lets have exceptions here, otherwise you will render type-hints
>useless (they are intended primarily for OO programmers anyway).
>
>I'm somewhat concerned that we are implementing a lot of the new OO
>features in a half-hearted fashion; I understand that there is a balance
>to maintain between easy-accessibility and "enterprise" features.

I think that we're having a very hard time defining this balance.

>I've mentioned several times now that unhandled exceptions look just
>like E_ERRORS to procedural/non-OO programmers; please can we have the
>new OO-related features throw exceptions rather than trigger E_ERRORS as
>it allows "real" programmers to write more robust code.

I'm very much against it.  I'm extremely worried about the perception of
PHP, and losing its perhaps only advantage to other languages, and that's
ease of use.  Even OO should be as simple as possible unless you start
using advanced features.

We should keep this stuff as errors, and not exceptions.  I still think we
can have a mode where recoverable errors will throw exceptions instead of
erroring out, so users will be able to explicitly ask for exceptions if
they wish, and won't see exceptions otherwise.  Remember that we don't want
to encourage exception based programming anyway.  Catching an exception
should typically be the last thing done in a program, right before it
terminates.  Writing exception-driven applications is extremely
discouraged.  So, in the cases we're dealing with, there should be very
little reason to catch an exception, rather than just error out with the
right error message.  For the cases where it does make sense, I think the
exceptions-for-errors mode would suffice.

Zeev

Per Lundberg

23 years ago

On Sat, 2003-03-29 at 12:59, Zeev Suraski wrote:

> Remember that we don't want to encourage exception based programming anyway.
> Catching an exception should typically be the last thing done in a program,
> right before it terminates.  Writing exception-driven applications is
> extremely discouraged.

What is the rationale behind this?

--
Best regards,

Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.capio.com

Zeev Suraski

23 years ago

At 11:35 31/03/2003, Per Lundberg wrote:

>On Sat, 2003-03-29 at 12:59, Zeev Suraski wrote:
> > Remember that we don't want to encourage exception based programming
> anyway.
> > Catching an exception should typically be the last thing done in a program,
> > right before it terminates.  Writing exception-driven applications is
> > extremely discouraged.
>
>What is the rationale behind this?

(a) This is very much the case for all languages that have
exceptions.  Exception handling is *slow*.  Coding exception-driven apps in
Java and C++ is a bad idea too.  Exceptions were designed to handle errors,
and not provide some nifty way of shifting control from one place to another.
(b) In PHP, exception handling results in memory leaks.  Like all leaks in
PHP, they'd be taken care of at the end of the request.  Until the end of
the request, however, certain chunks of memory will not be reclaimed.

Zeev

Per Lundberg

23 years ago

On Mon, 2003-03-31 at 10:53, Zeev Suraski wrote:

> At 11:35 31/03/2003, Per Lundberg wrote:
> >On Sat, 2003-03-29 at 12:59, Zeev Suraski wrote:
> > > Writing exception-driven applications is extremely discouraged.
> >What is the rationale behind this?
> (a) This is very much the case for all languages that have
> exceptions.  Exception handling is *slow*.  Coding exception-driven apps in
> Java and C++ is a bad idea too.  Exceptions were designed to handle errors,
> and not provide some nifty way of shifting control from one place to another.

I agree.  But is it a problem if error handling is slow?  I mean,
errors are not the normal flow of the application, and need not be
optimized as such.

If it slows down the code too much even when the exception is not
thrown, I can agree with your reasoning.  And yes, there are certainly
cases where exceptions are being used when not really neccessary.

> (b) In PHP, exception handling results in memory leaks.  Like all leaks in
> PHP, they'd be taken care of at the end of the request.  Until the end of
> the request, however, certain chunks of memory will not be reclaimed.

This could turn out to be a big problem for people developing non-web
applications with PHP, applications running for a long time.  Why do
exception handling leak?  Would it be impossible/very hard to fix this
behavior?


Another thing that just hit me: it would be incredibly useful to do like
this:

try {
eval($string);
}
catch (FatalErrorException $e) {
// handle the error.
}

Imagine the scenario with a standalone application loading in some
script from the user's home directory.  It would really be very bad if
the application just died here; it would limit the usability of the Zend
Engine for such an application a lot.

Yes, eval could be changed to return an error code, but that would
slightly break BC since the eval is to return the return()-value from
the eval()'ed code.

Do you agree that exceptions would be very convenient for this kind of
code/situation?

--
Best regards,

Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.capio.com

Brian Moon

23 years ago

Has type hinting for functions been implemented in ZE2?

Brian.
dealnews.com

----- Original Message -----
From: "Timm Friebe" <thekid@thekid.de>
To: <engine2@lists.zend.com>
Cc: <internals@lists.php.net>
Sent: Thursday, March 27, 2003 10:16 AM
Subject: [PHP-DEV] Type hints revisited [IllegalArgumentException instead of
E_ERROR]


| I've implemented an additional feature for type hints that will throw an
| exception instead of bailing out in case an incorrect type is passed.
|
| Test script:
|
| <?php
|   class Date { }
|   class Article {
|     public function setCreated_at(Date $date) {
|       echo __CLASS__, '::', __FUNCTION__, ' called with ';
|       var_export($date);
|       echo "\n";
|     }
|
|     public function setLastchange([Date] $date) {
|       echo __CLASS__, '::', __FUNCTION__, ' called with ';
|       var_export($date);
|       echo "\n";
|     }
|   }
|
|   $a= new Article();
|   $a->setLastchange(new Date());
|   $a->setLastchange(NULL);  // Passes
|   $a->setCreated_at(new Date());
|
|   try {
|     $a->setCreated_at(NULL);  // Fails
|   } catch (IllegalArgumentException $e) {
|     echo "Caught: "; var_dump($e);
|   }
|
|   $a->setCreated_at(1); // Fails
|   echo "Alive";         // Will not show up
| ?>
|
| Output:
| ---------------------------------------------------------------------
| thekid@friebes:~/devel/php > ./php5/sapi/cli/php hints.php
| article::setlastchange called with class date {
| }
| article::setlastchange called with NULL
| article::setcreated_at called with class date {
| }
| Caught: object(illegalargumentexception)#2 (3) {
|   ["message"]=>
|   string(38) "Argument 1 must be an instance of date"
|   ["file"]=>
|   string(36) "/usr/home/thekid/devel/php/hints.php"
|   ["line"]=>
|   int(4)
| }
|
| Fatal error: Uncaught exception! in Unknown on line 0
| ---------------------------------------------------------------------
|
| A unified diff is attached.
|
| - Timm
|


----------------------------------------------------------------------------
----


| --
| PHP Internals - PHP Runtime Development Mailing List
| To unsubscribe, visit: http://www.php.net/unsub.php

Timm Friebe

23 years ago

On Thu, 2003-03-27 at 18:32, Brian Moon wrote:

> Has type hinting for functions been implemented in ZE2?

Type hints apply to global functions just as they do for class methods.

<?php
class Date {
private
$utime    = 0;

public function __construct($arg= -1) {
if (is_int($arg)) {
$this->utime= $arg < 0 ? time() : $arg;
} else {
$this->utime= strtotime($arg);
}
}

public function toString($fmt= 'r') {
return date($fmt, $this->utime);
}
}

function print_date(Date $date, $fmt) {
echo $date->toString($fmt);
}

print_date(new Date(), $argv[1]);
echo "\n";
?>
thekid@friebes:~/devel/php > ./php5/sapi/cli/php date.php "Y-m-d"
2003-03-27

- Timm

Brian Moon

23 years ago

Ok, sorry, I have been off the ZE2 list for a while (just joined back).

Where is there more info on what the type hints do in ZE2.  I am curious as
I wrote the RFC.

Brian.
dealnews

----- Original Message -----
From: "Timm Friebe" <thekid@thekid.de>
To: "Brian Moon" <brianm@dealnews.com>
Cc: <engine2@lists.zend.com>; <internals@lists.php.net>
Sent: Thursday, March 27, 2003 11:40 AM
Subject: Re: [PHP-DEV] Type hints revisited [IllegalArgumentException
instead of E_ERROR]


| On Thu, 2003-03-27 at 18:32, Brian Moon wrote:
| > Has type hinting for functions been implemented in ZE2?
|
| Type hints apply to global functions just as they do for class methods.
|
| <?php
|   class Date {
|     private
|       $utime    = 0;
|
|     public function __construct($arg= -1) {
|       if (is_int($arg)) {
|         $this->utime= $arg < 0 ? time() : $arg;
|       } else {
|         $this->utime= strtotime($arg);
|       }
|     }
|
|     public function toString($fmt= 'r') {
|       return date($fmt, $this->utime);
|     }
|   }
|
|   function print_date(Date $date, $fmt) {
|     echo $date->toString($fmt);
|   }
|
|   print_date(new Date(), $argv[1]);
|   echo "\n";
| ?>
| thekid@friebes:~/devel/php > ./php5/sapi/cli/php date.php "Y-m-d"
| 2003-03-27
|
| - Timm
|
|
| --
| PHP Internals - PHP Runtime Development Mailing List
| To unsubscribe, visit: http://www.php.net/unsub.php
|
|
|

Timm Friebe

23 years ago

On Thu, 2003-03-27 at 18:45, Brian Moon wrote:

> Ok, sorry, I have been off the ZE2 list for a while (just joined back).
>
> Where is there more info on what the type hints do in ZE2.  I am curious as
> I wrote the RFC.

Zend/ZEND_CHANGES includes a section about type hints.

I suggested allowing NULLs, too, and (following a suggestion by Marcus
Börger) implemented a special syntax denoting NULL may also be passed.
The implementation probably sucks, leaks memory or does something else
which is really evil; it works for me, though:)

Source and documentation diff for this can be found in the patch of my
original mail to these lists.

- Timm

Andi Gutmans

23 years ago

At 06:55 PM 3/27/2003 +0100, Timm Friebe wrote:

>On Thu, 2003-03-27 at 18:45, Brian Moon wrote:
> > Ok, sorry, I have been off the ZE2 list for a while (just joined back).
> >
> > Where is there more info on what the type hints do in ZE2.  I am curious as
> > I wrote the RFC.
>
>Zend/ZEND_CHANGES includes a section about type hints.
>
>I suggested allowing NULLs, too, and (following a suggestion by Marcus
>Börger) implemented a special syntax denoting NULL may also be passed.
>The implementation probably sucks, leaks memory or does something else
>which is really evil; it works for me, though:)

I must admit that I am still undecided on the NULL issue :)

Andi

(Marcus Börger)

23 years ago

At 19:13 27.03.2003, Andi Gutmans wrote:

>At 06:55 PM 3/27/2003 +0100, Timm Friebe wrote:
>>On Thu, 2003-03-27 at 18:45, Brian Moon wrote:
>> > Ok, sorry, I have been off the ZE2 list for a while (just joined back).
>> >
>> > Where is there more info on what the type hints do in ZE2.  I am
>> curious as
>> > I wrote the RFC.
>>
>>Zend/ZEND_CHANGES includes a section about type hints.
>>
>>I suggested allowing NULLs, too, and (following a suggestion by Marcus
>>Börger) implemented a special syntax denoting NULL may also be passed.
>>The implementation probably sucks, leaks memory or does something else
>>which is really evil; it works for me, though:)
>
>I must admit that I am still undecided on the NULL issue :)

So what are your thought's here?

I for one do not see any usage in allowing NULL for parameters passed by
reference.

marcus

Andi Gutmans

23 years ago

At 10:43 PM 3/27/2003 +0100, Marcus Börger wrote:

>At 19:13 27.03.2003, Andi Gutmans wrote:
>>At 06:55 PM 3/27/2003 +0100, Timm Friebe wrote:
>>>On Thu, 2003-03-27 at 18:45, Brian Moon wrote:
>>> > Ok, sorry, I have been off the ZE2 list for a while (just joined back).
>>> >
>>> > Where is there more info on what the type hints do in ZE2.  I am
>>> curious as
>>> > I wrote the RFC.
>>>
>>>Zend/ZEND_CHANGES includes a section about type hints.
>>>
>>>I suggested allowing NULLs, too, and (following a suggestion by Marcus
>>>Börger) implemented a special syntax denoting NULL may also be passed.
>>>The implementation probably sucks, leaks memory or does something else
>>>which is really evil; it works for me, though:)
>>
>>I must admit that I am still undecided on the NULL issue :)
>
>
>So what are your thought's here?
>
>I for one do not see any usage in allowing NULL for parameters passed by
>reference.

By reference or also by value?

Andi

(Marcus Börger)

23 years ago

At 03:04 28.03.2003, Andi Gutmans wrote:

>At 10:43 PM 3/27/2003 +0100, Marcus Börger wrote:
>>At 19:13 27.03.2003, Andi Gutmans wrote:
>>>At 06:55 PM 3/27/2003 +0100, Timm Friebe wrote:
>>>>On Thu, 2003-03-27 at 18:45, Brian Moon wrote:
>>>> > Ok, sorry, I have been off the ZE2 list for a while (just joined back).
>>>> >
>>>> > Where is there more info on what the type hints do in ZE2.  I am
>>>> curious as
>>>> > I wrote the RFC.
>>>>
>>>>Zend/ZEND_CHANGES includes a section about type hints.
>>>>
>>>>I suggested allowing NULLs, too, and (following a suggestion by Marcus
>>>>Börger) implemented a special syntax denoting NULL may also be passed.
>>>>The implementation probably sucks, leaks memory or does something else
>>>>which is really evil; it works for me, though:)
>>>
>>>I must admit that I am still undecided on the NULL issue :)
>>
>>
>>So what are your thought's here?
>>
>>I for one do not see any usage in allowing NULL for parameters passed by
>>reference.
>
>By reference or also by value?

I guess NULL in case of by value is often used and it makes sense.

marcus

Timm Friebe

23 years ago

On Thu, 2003-03-27 at 17:16, Timm Friebe wrote:

> I've implemented an additional feature for type hints that will throw an
> exception instead of bailing out in case an incorrect type is passed.

[...LONG disussion...]

After reading through a bunch of mails this generated, I get the idea
that most people here would be happier with an E_WARNING and the
function not being executed.

That gives:
- the OOP purist the possibility to throw an exception (in a userland
error handler)
- the SOAP server a way to nicely recover
- the API designer a way to tell the user (s)he's messed up
- the "standard" programmer what (s)he's used to (PHP is quite
forgiving in the way it handles incorrect argument types and
usually warns about this)

Attached is the E_WARNING variant, an example script and its output.

- Timm

Zeev Suraski

23 years ago

At 07:15 29/03/2003, Timm Friebe wrote:

>On Thu, 2003-03-27 at 17:16, Timm Friebe wrote:
> > I've implemented an additional feature for type hints that will throw an
> > exception instead of bailing out in case an incorrect type is passed.
>[...LONG disussion...]
>
>After reading through a bunch of mails this generated, I get the idea
>that most people here would be happier with an E_WARNING and the
>function not being executed.

?!

How the heck can we even think about such a thing?  When you call a
function, you expect it to run.  The code that follows it may rely on stuff
that it has done.  Not running it is simply not an option, I can't even
begin to imagine the possible consequences of such an approach!

Type hints are shortcuts for instanceof.  If you want to handle a situation
where the function is passed the wrong arguments, don't use type hints, use
instanceof.  Or use the errors-for-exceptions mode that we may have.

Zeev

Timm Friebe

23 years ago

On Sat, 2003-03-29 at 13:10, Zeev Suraski wrote:
[...]

> >After reading through a bunch of mails this generated, I get the idea
> >that most people here would be happier with an E_WARNING and the
> >function not being executed.
>
> ?!
>
> How the heck can we even think about such a thing?  When you call a
> function, you expect it to run.  The code that follows it may rely on stuff
> that it has done.  Not running it is simply not an option, I can't even
> begin to imagine the possible consequences of such an approach!

Well, at the moment, the function is not run either, isn't it? The
program dies.

To clarify:

function foo(Bar $bar) {
// [...]
}

is - with my patch - equivalent to:

function foo($bar) {
if (!($bar instanceof Bar)) {
trigger_error('Argument 1 must be an instance of Bar', E_WARNING);
return;
}

// [...]
}

and basically much nicer as a function containing - say - five or six
arguments all needing to be checked in the "not-instance-of" manner.

At the moment, it is:

function foo($bar) {
if (!($bar instanceof Bar)) {
die('Argument 1 must be an instance of Bar');
}

// [...]
}

That's all I changed.

> Type hints are shortcuts for instanceof.  If you want to handle a situation
> where the function is passed the wrong arguments, don't use type hints, use
> instanceof.  Or use the errors-for-exceptions mode that we may have.

I guess, as we can't find a consensus here, that is what has to be done.

- Timm

Zeev Suraski

23 years ago

At 16:23 29/03/2003, Timm Friebe wrote:

>On Sat, 2003-03-29 at 13:10, Zeev Suraski wrote:
>[...]
> > >After reading through a bunch of mails this generated, I get the idea
> > >that most people here would be happier with an E_WARNING and the
> > >function not being executed.
> >
> > ?!
> >
> > How the heck can we even think about such a thing?  When you call a
> > function, you expect it to run.  The code that follows it may rely on
> stuff
> > that it has done.  Not running it is simply not an option, I can't even
> > begin to imagine the possible consequences of such an approach!
>
>Well, at the moment, the function is not run either, isn't it? The
>program dies.

Right.  Code assuming that it ran successfully is therefore never
reached.  That is fundamentally different from just not running the
function and returning control to the caller.  That's *extremely* dangerous.

Zeev

Harald Radi

23 years ago

> > > that it has done.  Not running it is simply not an option, I can't even
> > > begin to imagine the possible consequences of such an approach!
> >
> >Well, at the moment, the function is not run either, isn't it? The
> >program dies.
>
> Right.  Code assuming that it ran successfully is therefore never
> reached.  That is fundamentally different from just not running the
> function and returning control to the caller.  That's
> *extremely* dangerous.

wouldn't an exception be the absolutely right thing here then ? - just teasing
you, i know your point :P

harald

Wez Furlong

23 years ago

How does this differ from the return values of functions using
WRONG_PARAM_COUNT and zend_parse_parameters()?

--Wez

On Sat, 29 Mar 2003, Zeev Suraski wrote: