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
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 __construct
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
thanks Stas. I'll think on next week.
Dmitry.
On Fri, Nov 21, 2014 at 6:59 AM, Stanislav Malyshev
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" usage in z
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:
https://github.com/smalyshev/php-src/compare/php:master...s
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 cod
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
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
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).
T
Andrea Faulds wrote on 20/11/2014 09:38:
On 20 Nov 2014, at 09:34, Rowan Collins 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 ti
> On 20 Nov 2014, at 09:34, Rowan Collins 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 = 0;
> ++$a; // 1
>
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 reali
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 ch
On Thu, Nov 20, 2014 at 9:44 AM, Bradley Weston
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 except one.
--
Ferenc Ko
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
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
> parent::__co
t (by making a special case
for parent::__construct)"
-- SLevy
- Original Message -
From: "Rowan Collins"
To: "Stanislav Malyshev" ; "Marco Pivetta"
Cc: "PHP Internals List"
Sent: Wednesday, November 19, 2014 1:21 AM
Subject: Re: [PHP-DEV]
On 19 November 2014 01:50:33 GMT, Stanislav Malyshev
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 on the table
On 19 November 2014 01:50:33 GMT, Stanislav Malyshev
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 wrong).
Quit
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 co
On 19 November 2014 01:05, Stanislav Malyshev 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 as it is i
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
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( print('hel
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
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 fu
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
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
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 mist
> On 18 Nov 2014, at 22:54, Stanislav Malyshev 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
> should not be s
On 18/11/2014 21:53, Andrea Faulds wrote:
On 18 Nov 2014, at 21:51, Rowan Collins 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
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
should not be so, and it should be changed, that's fine, but it's not
what is called a
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 v
> On 18 Nov 2014, at 21:51, Rowan Collins 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( print('hello') );
> /
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*. Th
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
(
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 chang
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 wou
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
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 implica
> On 18 Nov 2014, at 19:00, Stanislav Malyshev 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
>> featur
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
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
Hi!
2014-11-18 12:20 GMT+03:00 Stanislav Malyshev :
>
> 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 of default
constr
Andrea Faulds wrote on 18/11/2014 13:11:
On 18 Nov 2014, at 12:47, Ferenc Kovacs 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 th
> On 18 Nov 2014, at 12:47, Ferenc Kovacs 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`?
> ye
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
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 ctor
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 i
On Tue, Nov 18, 2014 at 10:20 AM, 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
> -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
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:
http://php100.wordpress.com/2014/11/
51 matches
Mail list logo
