FAQ
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

Search Discussions

  • Andi Gutmans at Mar 27, 2003 at 4:57 pm

    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

    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
  • George Schlossnagle at Mar 27, 2003 at 5:03 pm

    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 at Mar 27, 2003 at 5:10 pm

    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 at Mar 27, 2003 at 5:51 pm

    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 at Mar 27, 2003 at 5:56 pm

    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 at Mar 27, 2003 at 6:12 pm

    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 at Mar 27, 2003 at 6:13 pm

    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 at Mar 27, 2003 at 5:13 pm

    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
  • Andi Gutmans at Mar 27, 2003 at 5:57 pm

    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
  • Per Lundberg at Mar 27, 2003 at 5:20 pm

    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
  • Andi Gutmans at Mar 27, 2003 at 6:14 pm

    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 at Mar 27, 2003 at 7:08 pm

    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 at Mar 27, 2003 at 8:42 pm

    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 at Mar 28, 2003 at 7:27 am
    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
  • Shane Caraveo at Mar 27, 2003 at 5:42 pm
    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:
    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
  • Andi Gutmans at Mar 27, 2003 at 6:00 pm

    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 at Mar 27, 2003 at 6:26 pm

    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 at Mar 27, 2003 at 8:28 pm

    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
  • Wez Furlong at Mar 27, 2003 at 9:49 pm
    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:
    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 Gutmans at Mar 28, 2003 at 7:14 am

    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 at Mar 28, 2003 at 7:43 am
    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 at Mar 28, 2003 at 8:35 am

    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 at Mar 29, 2003 at 1:26 am
    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 at Mar 29, 2003 at 1:56 am
    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:
    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.
  • Per Lundberg at Mar 31, 2003 at 8:41 am

    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
  • Andi Gutmans at Mar 28, 2003 at 2:02 pm
    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:
    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


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Manuel Lemos at Mar 29, 2003 at 1:29 am
    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 at Mar 29, 2003 at 7:36 am

    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 at Mar 29, 2003 at 11:41 am
    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 at Mar 29, 2003 at 11:46 am

    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 at Mar 29, 2003 at 12:01 pm
    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 at Mar 29, 2003 at 12:47 pm

    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.
  • Manuel Lemos at Mar 29, 2003 at 1:38 pm
    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
  • Derick Rethans at Mar 29, 2003 at 1:40 pm

    On Sat, 29 Mar 2003, Manuel Lemos wrote:

    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
    There are no nested namespaces there, just classes in a namespace.

    Derick

    --
    "my other box is your windows PC"
    -------------------------------------------------------------------------
    Derick Rethans http://derickrethans.nl/
    PHP Magazine - PHP Magazine for Professionals http://php-mag.net/
    -------------------------------------------------------------------------
  • Derick Rethans at Mar 29, 2003 at 1:41 pm

    On Sat, 29 Mar 2003, Manuel Lemos wrote:

    Maybe that is why the output of the example in that page is a parse
    error! ;-)
    No, the machine runs PHP 4, the code is PHP 5 only.

    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 at Mar 29, 2003 at 2:00 pm
    Hello,
    On 03/29/2003 10:41 AM, Derick Rethans wrote:
    Maybe that is why the output of the example in that page is a parse
    error! ;-)

    No, the machine runs PHP 4, the code is PHP 5 only.
    Of course (notice the smiley ;-) ).

    Maybe Sebastian needs to upgrade his PHP 5 version or at least agree on
    nomenclature with Sterling! :-)

    Seriously, this just reinforce my point that it is odd that that package
    level access restrictions is out because according to Andi it is
    confusing, but then other even more confusing features are added like
    nested namespaced or whatever you want to call them.

    It seems to me that the reasoning is not being done by real OOP
    practioners, ie, people that develop OOP based applications every day or
    else they would feel the need for features like package level access
    restrictions.

    Never mind, I just wanted to know if the reasoning for not having that
    feature had to due to any run-time performance loss and it seems that is
    not the reason.

    As I said before it is not important for me. I am just evaluating if
    there is any point in making MetaL generate PHP 5 optimized code. MetaL
    is used by Metastorage to generate optimized code persistence layers to
    support rapid development of enterprise level application, which is one
    thing that PHP seriously lacks.

    http://www.meta-language.net/metastorage.html

    If there is no point in generating PHP 5 optimized code as an option, I
    hope PHP 4 compliant that MetaL generates will work well with PHP 5.


    --

    Regards,
    Manuel Lemos
  • Timm Friebe at Mar 29, 2003 at 1:43 pm

    On Sat, 2003-03-29 at 14:38, Manuel Lemos wrote:
    Hello, [...]
    http://talks.php.net/show/php5intro/4

    Maybe that is why the output of the example in that page is a parse
    error! ;-)
    That's because the webserver is running PHP4.

    thekid@friebes:~/devel/php > cat | ./php5/sapi/cli/php
    <?php
    namespace Languages:Perl {
    class Execute {
    function statement($cmd) {
    $cmd = escapeshellcmd($cmd);
    system("echo $cmd | perl");
    }
    }

    class Insult {
    function oneLiner() {
    echo "Perl is soo ugly, even ";
    echo "Microsoft can't embrace it";
    echo "\n<br />\n";
    }
    }
    }

    $e = new Languages:Perl::Execute;
    $e->statement("print 'Hello World!'");
    echo "\n<br />\n";
    $i = new Languages:Perl::Insult;
    $i->oneLiner();
    ?>
    ^D
    Hello World!
    <br />
    Perl is soo ugly, even Microsoft can't embrace it
    <br />

    - Timm
  • Sterling Hughes at Mar 29, 2003 at 1:58 pm

    On Sat, 2003-03-29 at 08:38, Manuel Lemos wrote:
    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! ;-)
    *Syntactic Sugar* meaning: its meaningless. :=)

    It generates a parse error because php4 is installed on that machine.
    php5 can't sustain a slashdot load, so the php5 server was taken down
    (ny1.php.net).

    -Sterling


    --

    Regards,
    Manuel Lemos
    --
    "Reductionists like to take things apart. The rest of us are
    just trying to get it together."
    - Larry Wall, Programming Perl, 3rd Edition
  • Wez Furlong at Mar 28, 2003 at 10:04 am
    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:
    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

  • Per Lundberg at Mar 28, 2003 at 10:09 am

    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
  • Andi Gutmans at Mar 28, 2003 at 2:03 pm

    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 at Mar 28, 2003 at 2:05 pm

    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 at Mar 28, 2003 at 3:01 pm

    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 at Mar 28, 2003 at 3:36 pm

    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 at Apr 3, 2003 at 5:18 pm

    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 at Mar 28, 2003 at 3:42 pm

    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 at Mar 28, 2003 at 5:14 pm

    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 at Mar 28, 2003 at 6:17 pm

    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 at Apr 3, 2003 at 5:18 pm

    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 at Apr 6, 2003 at 12:33 pm

    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

Related Discussions

People

Translate

site design / logo © 2022 Grokbase