Hi Stas,
On Mon, Mar 2, 2015 at 7:05 AM, Stanislav Malyshev
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_beha
Hi all,
On Tue, Mar 3, 2015 at 4:27 PM, Michael Wallner wrote:
> >
> >> 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
> >> explicitly ask for that behavior?
> >
> > I can't say I am familiar with every OO lan
>> 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.
>
> Of course, consistency with userland is beneficial. However, in userland
> we do not have many things that we have
Hi!
> I'm not sure I can understand your crusade against this topic.
I would start with trying to address my actual arguments, as opposed to
dismissing it as a "crusade". I've described my arguments for it in my
previous emails, is there something unclear there? I'd be happy to
explain any point
On 02/03/15 07:57, Michael Wallner wrote:
> 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 p
On 02/03/15 04:10, Stanislav Malyshev wrote:
>> Because the programmer should only be passing in valid paramters any
>> > failure is by it's nature an unexpected error.
> That's exactly like saying programmer should only try to open existing
> files so any failure by its nature is an unexpected err
On 01/03/15 23:05, Stanislav Malyshev 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 t
Hi!
> 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
Failure of the formatter on wrong format or data is of the same kind -
its not e
Hi!
> 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.
I'm sorry, I have hard time understanding what exceptions have to do
wi
On 1 March 2015 at 22:05, Stanislav Malyshev wrote:
> 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
Hi Stas,
On Mon, Mar 2, 2015 at 7:05 AM, Stanislav Malyshev
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
>
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
returni
Am 01.03.2015 um 20:04 schrieb Dan Ackroyd:
On 1 March 2015 at 18:35, Marc Bennewitz wrote:
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
On 1 March 2015 at 18:35, Marc Bennewitz wrote:
> 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. Obviou
Hi Dan,
Am 01.03.2015 um 15:55 schrieb Dan Ackroyd:
Hi Internals,
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 really like this R
On 1 Mar 2015 15:56, "Dan Ackroyd" wrote:
>
> Hi Internals,
>
> 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
>
> For reference t
Hi Internals,
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
For reference this was discussed before
https://marc.info/?l=php-internals&
17 matches
Mail list logo
