[RFC][DISCUSSION] Constructor behaviour of internal classes

What are the reasons to not make this class instantiable / extendable ?

That class handles database state / resources that are not exposed
through the userland classes. It's correct in my opinion for it to not
be extendible or instantiable. Obviously it would be awesome if they
were covered by an interface, to allow testign to be easier, but
that's a separate issue.

That's definitely better but it's an behavior not possible to implemented in
user land code as it would be impossible to get such an object.

The same behaviour can seen with the code below.

cheers
Dan

class Foo {

private static $internalConstruction = false;

public function __construct() {
    $constructionAllowed = !self::$internalConstruction;
    self::$internalConstruction = false;

    if ($constructionAllowed == false) {
        throw new \Exception("External construction not allowed");
    }
}

public static function create() {
    self::$internalConstruction = true;
    return new self();
}

}

$foo = Foo::create();
var_dump($foo);
$bar = new Foo();

Hi Stas,

On Mon, Mar 2, 2015 at 7:05 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:

This email is to announce the formal opening of discussion for an RFC
to clean up the behaviour of the constructors shown by several
internal classes.

https://wiki.php.net/rfc/internal_constructor_behaviour

I'm not sure why this RFC assumes the exception is much better than
returning null. Exceptions are harder to handle (requires separate
syntax construct) and they are more expensive at runtime (must create an
object, collect the backtrace, etc.). Also, not catching the exception
immediately usually will lead to a complete application failure (usually
with an obscure error message like "internal operation failed", since
displaying raw exceptions to the user can be unsafe) instead of
finer-grained handling.
It is a long standing tradition in PHP that operations that can be
expected to fail - like fopen(), date_create(), etc. - do not produce
fatal errors but instead return error values which can be checked for
and handled. It is true that some SPL classes departed from that, but
this IMO was not an improvement but rather an annoyance that each time
you use an SPL thing you have to write it in a try/catch block. That
leads to much more boilerplate code than necessary.

Now I understand that PHP model of doing things may be unusual for some
people that come from other language background where everything throws
exceptions for any slightest reason and there's no other means of error
checking. But I think we can do better rather than that and have more
flexible error handling - even if it would require people to be
introduced to a concept they were not familiar with before coming to
PHP, such as not using exceptions for everything.

I can understand your argument. It works.

This proposal is about code modularization. Software engineering is
a history of better modularization.

• Structured programming
• Object Oriented programming
• AOP
• DbC

Exception is one of them.

While error handling without exception works, it decreases modularization.
Therefore, it decreases maintainability and increases chance of bugs.

Besides modularization, consistency is important for programming language
also.

These are the topic/objective for this RFC. IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

I'm not sure why this RFC assumes the exception is much better than
returning null.

It is a long standing tradition in PHP that operations that can be
expected to fail - like fopen().. do not produce
fatal errors but instead return error values which can be checked for
and handled.

The difference is that fopen can fail even if passed parameters that
are correct e.g. due to file permission problems. Because of that the
failure is not exceptional and so needs to be checked. Having to do
this through exceptions would be annoying which is why people prefer
to use procedural function for handling files, even when OO style
interfaces are available.

When a user calls new NumberFormatter() they can know ahead of time
whether the parameters are valid or not. Any call with valid
parameters will succeed. Calls with invalid parameters will fail.
Because the programmer should only be passing in valid paramters any
failure is by it's nature an unexpected error.

And to be precise, fopen does not return error values. It returns a
single error value of false. There is no indication of why the error
occurred. Exceptions allow a message to be attached saying what went
wrong, which is why they are preferred in a lot of cases.

But I think we can do better rather than that and have more
flexible error handling - even if it would require people to be
introduced to a concept they were not familiar with before coming to
PHP, such as not using exceptions for everything.

You are one of the very few people who don't like exceptions. I
completely agree exceptions shouldn't be used everywhere and that they
should be used only for exception circumstances. But the vast majority
of PHP programmers are completely used to them.

If you don't see the benefits of using exceptions in some cases by
now, it's very unlikely that any argument is going to persuade you of
how they can be used (judiciously) to write clean code.

Luckily, this RFC isn't a general discussion about error handling, it
is specifically about the behaviour of internal classes being
'special' either by having behaviour which is not possible for
userland classes to do, or just being unusable after being
instantiated due to incorrect parameters.

cheers
Dan

Hi!

This email is to announce the formal opening of discussion for an RFC
to clean up the behaviour of the constructors shown by several
internal classes.

https://wiki.php.net/rfc/internal_constructor_behaviour

I'm not sure why this RFC assumes the exception is much better than
returning null. Exceptions are harder to handle (requires separate
syntax construct) and they are more expensive at runtime (must create an
object, collect the backtrace, etc.). Also, not catching the exception
immediately usually will lead to a complete application failure (usually
with an obscure error message like "internal operation failed", since
displaying raw exceptions to the user can be unsafe) instead of
finer-grained handling.
It is a long standing tradition in PHP that operations that can be
expected to fail - like fopen(), date_create(), etc. - do not produce
fatal errors but instead return error values which can be checked for
and handled. It is true that some SPL classes departed from that, but
this IMO was not an improvement but rather an annoyance that each time
you use an SPL thing you have to write it in a try/catch block. That
leads to much more boilerplate code than necessary.

Now I understand that PHP model of doing things may be unusual for some
people that come from other language background where everything throws
exceptions for any slightest reason and there's no other means of error
checking. But I think we can do better rather than that and have more
flexible error handling - even if it would require people to be
introduced to a concept they were not familiar with before coming to
PHP, such as not using exceptions for everything.

I'm not sure I can understand your crusade against this topic.

Consistency with userland is beneficial, because the majority of PHP
developers probably do not expect new to yield anything than a
concrete instance or an exception.

Quoting php.net/manual:

To create an instance of a class, the new keyword must be used. An

object will always be created unless the object has a constructor
defined that throws an exception on error.

Emphasis mine.

Do you know of any other case where a new operator in an object
oriented context can return NULL, except C++ where you have to
explicitely ask for that behavior?

--
Regards,
Mike

Hi Stas,

On Mon, Mar 2, 2015 at 7:05 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

This email is to announce the formal opening of discussion for an RFC
to clean up the behaviour of the constructors shown by several
internal classes.

https://wiki.php.net/rfc/internal_constructor_behaviour

I'm not sure why this RFC assumes the exception is much better than
returning null. Exceptions are harder to handle (requires separate
syntax construct) and they are more expensive at runtime (must create an
object, collect the backtrace, etc.). Also, not catching the exception
immediately usually will lead to a complete application failure (usually
with an obscure error message like "internal operation failed", since
displaying raw exceptions to the user can be unsafe) instead of
finer-grained handling.
It is a long standing tradition in PHP that operations that can be
expected to fail - like fopen(), date_create(), etc. - do not produce
fatal errors but instead return error values which can be checked for
and handled. It is true that some SPL classes departed from that, but
this IMO was not an improvement but rather an annoyance that each time
you use an SPL thing you have to write it in a try/catch block. That
leads to much more boilerplate code than necessary.

Now I understand that PHP model of doing things may be unusual for some
people that come from other language background where everything throws
exceptions for any slightest reason and there's no other means of error
checking. But I think we can do better rather than that and have more
flexible error handling - even if it would require people to be
introduced to a concept they were not familiar with before coming to
PHP, such as not using exceptions for everything.

I come up with better idea for both procedural and OO style error handling.
The other day, I wrote simple PostgreSQL and MongoDB benchmark
script to see how PostgreSQL outperforms MongoDB.
(PostgreSQL 9.4 is about 30% faster than MongoDB 2.6, BTW)

https://gist.github.com/yohgaki/a11a2f435f3d8f6ee096

For this kind of simple procedural code, exceptions are useless or even
harmful. If there is a RFC that ignores unhandled exceptions, no try block
and no default exception handler then ignore exception, I'll vote "yes" for
it.
Having this kind of switch would be great for procedural code and OO API
designers.

Just an idea.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net