I like the last patch. I think ZEND_ACC_STATIC flag must not make any
problems.
However, I thought about one more inconsistent. Your patch works fine for
parent:: methods but not for grandparents::
In the following code default constructor won't work.
class A {
}
class B extends A {
}
class C
Dmitry Stogov wrote on 24/11/2014 09:56:
However, I thought about one more inconsistent. Your patch works fine for
parent:: methods but not for grandparents::
In the following code default constructor won't work.
class A {
}
class B extends A {
}
class C extends B {
function __constructor()
Hi!
However, I thought about one more inconsistent. Your patch works fine
for parent:: methods but not for grandparents::
In the following code default constructor won't work.
Yes, this is OK - the support is only for one pattern, calling the
parent, because it's what you're supposed to do.
Somehow HHVM has this working http://3v4l.org/5AFSA
On 20/11/2014 00:44, Stanislav Malyshev wrote:
Hi!
The point of this discussion is that there is an RFC on the table
which can be implemented in such a way that it fixes this behaviour
(by introducing a default parent, or injecting an empty
On Thu, Nov 20, 2014 at 9:44 AM, Bradley Weston brad...@legalweb.org.uk
wrote:
Somehow HHVM has this working http://3v4l.org/5AFSA
it was mentioned early in the thread that hhvm is not copying the behavior
of php for optimizing out the execution of the argument if the constructor
doesn't
Sharon Levy wrote on 20/11/2014 00:34:
As a user, I like this feature since it seems sensible if one is
concerned with efficient code execution. Whereas the undefined
__construct {} permits the opcode to execute even tho' the resulting
value is useless for the class. If anything needs to
Stanislav Malyshev wrote on 20/11/2014 00:44:
This reminds me of the recent discussion over multiple defaults in a
switch. Perhaps as with that we should phrase the question as is
there any useful purpose to having the language standardised with
this feature, and conversely is there any
On 20 Nov 2014, at 09:34, Rowan Collins rowan.coll...@gmail.com wrote:
Note that there are many, many places where expressions are actioned for
their side effects even though the result is discarded. The following will
increment $a 3 times, even though it is discarded each time:
$a =
Andrea Faulds wrote on 20/11/2014 09:38:
On 20 Nov 2014, at 09:34, Rowan Collins rowan.coll...@gmail.com wrote:
Note that there are many, many places where expressions are actioned for their
side effects even though the result is discarded. The following will increment
$a 3 times, even though
Hi Stas,
Sorry, I didn't follow all the discussions.
I think the idea is good.
I'm not sure about implementation.
Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive.
I think it must be better to use special predefined function (see
zend_pass_function usage in zend_vm_def.h).
Hi!
I think the idea is good.
I'm not sure about implementation.
Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive.
I think it must be better to use special predefined function (see
zend_pass_function usage in zend_vm_def.h).
I've moved the condition after internal user
Hi!
Well, as others have pointed out, HHVM behaves differently in this case,
And?
so I guess what I'm getting at is: is this considered a feature *of the
language*, or just a known oddity of the *implementation*? If it's part
I do not think the standard should require it, as whoever using
Stanislav Malyshev wrote on 20/11/2014 18:47:
I do not think the standard should require it, as whoever using this for
anything, one way or another, is doing it very, very wrong, but that's
how it works now.
As I said before, I don't see anything very, very wrong about assuming
that this code
Hi!
Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive.
I think it must be better to use special predefined function (see
zend_pass_function usage in zend_vm_def.h).
I've made a different implementation here:
thanks Stas. I'll think on next week.
Dmitry.
On Fri, Nov 21, 2014 at 6:59 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive.
I think it must be better to use special predefined function (see
zend_pass_function
On 19 November 2014 01:50:33 GMT, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Is there a `.phpt` test-case or discussion backing this?
Backing what? Checking if side effects happen when evaluating args of
non-existing ctor? Probably not, since nobody ever needed it (correct
me
if I'm
On 19 November 2014 01:50:33 GMT, Stanislav Malyshev smalys...@gmail.com
wrote:
Yes, that's a bug :-)
No, it is not :)
We can do it all day but I think I've explained what is going on there.
If you want to change it, feel free to do the RFC.
The point of this discussion is that there is an RFC
Message -
From: Rowan Collins rowan.coll...@gmail.com
To: Stanislav Malyshev smalys...@gmail.com; Marco Pivetta
ocram...@gmail.com
Cc: PHP Internals List internals@lists.php.net
Sent: Wednesday, November 19, 2014 1:21 AM
Subject: Re: [PHP-DEV] [RFC] Default constructors
On 19 November 2014
Hi!
The point of this discussion is that there is an RFC on the table
which can be implemented in such a way that it fixes this behaviour
(by introducing a default parent, or injecting an empty constructor)
or such that it carefully preserves it (by making a special case for
Hi!
I'd like to propose the following RFC, which in short would allow any
method to call parent ctor (and some other methods) even if such is not
explicitly defined:
https://wiki.php.net/rfc/default_ctor
The reasons are outlined in detail in the RFC and here:
-Ursprüngliche Nachricht-
Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
Gesendet: Dienstag, 18. November 2014 10:21
An: PHP Internals
Betreff: [PHP-DEV] [RFC] Default constructors
Hi!
I'd like to propose the following RFC, which in short would allow any method
to call
On Tue, Nov 18, 2014 at 10:20 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
I'd like to propose the following RFC, which in short would allow any
method to call parent ctor (and some other methods) even if such is not
explicitly defined:
https://wiki.php.net/rfc/default_ctor
The
On Tue, 18 Nov 2014, Stanislav Malyshev wrote:
Hi!
I'd like to propose the following RFC, which in short would allow any
method to call parent ctor (and some other methods) even if such is not
explicitly defined:
https://wiki.php.net/rfc/default_ctor
The reasons are outlined in detail
Hello :-),
Is it not simpler to create a super-object whom all objects are children
of? Something similar to the Java `Object`?
Cheers :-).
Le 18/11/2014 10:20, Stanislav Malyshev a écrit :
Hi!
I'd like to propose the following RFC, which in short would allow any
method to call parent
On Tue, Nov 18, 2014 at 1:35 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hello :-),
Is it not simpler to create a super-object whom all objects are children
of? Something similar to the Java `Object`?
yeah, this was also a suggested alternative when discussing this problem
On 18 Nov 2014, at 12:47, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Nov 18, 2014 at 1:35 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hello :-),
Is it not simpler to create a super-object whom all objects are children
of? Something similar to the Java `Object`?
Andrea Faulds wrote on 18/11/2014 13:11:
On 18 Nov 2014, at 12:47, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Nov 18, 2014 at 1:35 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hello :-),
Is it not simpler to create a super-object whom all objects are children
of?
Hi!
2014-11-18 12:20 GMT+03:00 Stanislav Malyshev smalys...@gmail.com:
I'd like to propose the following RFC, which in short would allow any
method to call parent ctor (and some other methods) even if such is not
explicitly defined:
+1 for defining base class for all classes and addition
Hi!
You write:
Also, this can lead to more subtle BC breaks. Consider this code:
And then further on:
No backward incompatible changes, sin...
that can not be both right.
Ah, but the former describes the option that has been *rejected*. The
option that was chosen instead does not
Hi!
Thanks for bringing this up and working on the patch.
Last time we discussed
this(http://www.serverphorums.com/read.php?7,71,712635), there were
a couple of people including Anthony and Sanford who were agains this
feature arguing that it would encourage bad practices so I think it
On 18 Nov 2014, at 19:00, Stanislav Malyshev smalys...@gmail.com wrote:
Thanks for bringing this up and working on the patch.
Last time we discussed
this(http://www.serverphorums.com/read.php?7,71,712635), there were
a couple of people including Anthony and Sanford who were agains this
Hi!
I'd certainly like it if everything descended from some class (Object?
StdClass?), but I don't like the idea of an empty construct. As
Making everything descend from the same class may require a number of
changes and much bigger design effort than this RFC aims at, with wider
BC
Hi!
mean we should add this, though. Because this RFC means you can just
blindly call the constructor, whether or not it exists, and expect it
Yes, that's exactly what it means and it's good, not bad - new() has
been doing that for years and nobody complained.
to work. And that is bad: If
On 18/11/14 14:00, Stanislav Malyshev wrote:
Hi!
Thanks for bringing this up and working on the patch.
Last time we discussed
this(http://www.serverphorums.com/read.php?7,71,712635), there were
a couple of people including Anthony and Sanford who were agains this
feature arguing that it
Hi!
Does it *really* make sense for PHP? What if that parent class 'Animal'
from your example introduces a constructor that accepts, say, both
`$owner` and `$what` as mandatory arguments? `parent::__construct()`
Then you need to rewrite all descendant classes anyway, this would be
API change,
On 18/11/2014 20:20, Alexander Kurilo wrote:
Does it *really* make sense for PHP? What if that parent class
'Animal' from your example introduces a constructor that accepts, say,
both `$owner` and `$what` as mandatory arguments?
`parent::__construct()` call in a descendant will appear broken
On 18/11/2014 18:54, Stanislav Malyshev wrote:
Hi!
You write:
Also, this can lead to more subtle BC breaks. Consider this code:
And then further on:
No backward incompatible changes, sin...
that can not be both right.
Ah, but the former describes the option that has been *rejected*.
On 18 Nov 2014, at 21:51, Rowan Collins rowan.coll...@gmail.com wrote:
Personally, I would much prefer the backwards compatibility break to happen.
It is frankly quite bizarre, and not at all useful, that the following two
pieces of code behave differently:
class Foo {}
new Foo(
Hi!
Making everything descend from the same class may require a number of
changes and much bigger design effort than this RFC aims at, with wider
BC implications.
I am not sure, whether this might be a problem (I am just starting to
dive into PHP internals), but I can think of constructor
On 18/11/2014 21:53, Andrea Faulds wrote:
On 18 Nov 2014, at 21:51, Rowan Collins rowan.coll...@gmail.com wrote:
Personally, I would much prefer the backwards compatibility break to happen. It
is frankly quite bizarre, and not at all useful, that the following two pieces
of code behave
On 18 Nov 2014, at 22:54, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
In fact, it *is* a bug: https://bugs.php.net/bug.php?id=67829
It is most definitely not a bug, it's the intended behavior that has
been coded so and has been in PHP for a very long time. You may argue it
On 18/11/2014 22:54, Stanislav Malyshev wrote:
It is most definitely not a bug, it's the intended behavior that has
been coded so and has been in PHP for a very long time. You may argue it
should not be so, and it should be changed, that's fine, but it's not
what is called a bug - it's not a
Hi!
Are you sure it was intended to work this way, with the parameters
not being evaluated at all?
Of course, just look at how ZEND_NEW opcode is written. It's the only
reason in has op2 there. That code is not a typo, it's intended to skip
the function call.
Is that actually useful in any
Hi!
Been in PHP for a very long time != how it was intended to work. Can
you explain why this would be the intention of anyone designing the
language?
Of course, been for a long time is not the same as intended. But if you
look at how ZEND_NEW is done, it's clear it's intended. And the reason
On 18/11/2014 23:07, Stanislav Malyshev wrote:
Hi!
Are you sure it was intended to work this way, with the parameters
not being evaluated at all?
Of course, just look at how ZEND_NEW opcode is written. It's the only
reason in has op2 there. That code is not a typo, it's intended to skip
the
On 18/11/2014 23:11, Stanislav Malyshev wrote:
Been in PHP for a very long time != how it was intended to work. Can
you explain why this would be the intention of anyone designing the
language?
Of course, been for a long time is not the same as intended. But if you
look at how ZEND_NEW is done,
On 18/11/2014 23:20, Rowan Collins wrote:
If a fatal error is being raised, it makes (some) sense to skip that
evaluation
To be honest, it's a little weird to me that these two programs behave
differently:
$a = print('hello');
non_existent_function($a);
vs
non_existent_function(
Hi!
I'm happy to accept that this is a low-priority, hard-to-fix, bug. I
just don't see that it can be justified as a feature.
We can argue semantics of the word bug all day long, but the fact is
the functionality as it is is there by an explicit decision - it was
chosen to be this way and no
On 19 November 2014 01:05, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
I'm happy to accept that this is a low-priority, hard-to-fix, bug. I
just don't see that it can be justified as a feature.
We can argue semantics of the word bug all day long, but the fact is
the functionality
Hi!
Is there a `.phpt` test-case or discussion backing this?
Backing what? Checking if side effects happen when evaluating args of
non-existing ctor? Probably not, since nobody ever needed it (correct me
if I'm wrong). There are many weird scenarios of what you could do with
PHP that are not
50 matches
Mail list logo