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:
Of course, it would be great to always use zend_string, but only arg_info
duplication (without char - zend_string) would add ~90KB on 32-bit system
and ~150KB on 64-bit system per process. So I expect 300-500KB wasted per
process.
Actually, only inheritance and reflection code was complicated by
-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`?
Hi I found this email in PHP.net as a contact address for Web masters.
My question is about PHP SAPI C/C++ development.
I’ve successfully attached PHP to my C/C++ application as a SAPI module
with libphp.so , and it’s working now , but I have a problem with multiple
tasks in my application.
I
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
Any other input on this pull request? Are there tests that should be
duplicated to run in single vs multi query mode?
-Peter
On Fri, Nov 14, 2014 at 10:49 AM, Ferenc Kovacs tyr...@gmail.com wrote:
yeah, the consensus was to create feature request on bugs.php.net for PRs
(and link the PR from
Hi internals,
Library developers sometimes plan for extensibility of their code, but not
all pieces are able to be extended and unexpected usage can lead to
unpredictable behavior.
Based on that, I consider it may be a good addition to PHP to add class
visibility support and enhance existing
On 18 Nov 2014, at 17:33, guilhermebla...@gmail.com wrote:
Library developers sometimes plan for extensibility of their code, but not
all pieces are able to be extended and unexpected usage can lead to
unpredictable behavior.
Based on that, I consider it may be a good addition to PHP to
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 there,
the default build process of PHP on Unix/Linux links together all code
needed for any SAPI that one builds (excluding dynamically loadable
extensions). This often leads to relatively big SAPI shared object
files. But most of this code is exactly the same for all SAPIs. That
adds
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,
Hi!
The vote for https://wiki.php.net/rfc/secure_unserialize has been
completed (actually, should be last week but I was busy, sorry for the
delay) and the RFC is accepted 17 votes for to 6 votes against.
Now, there were proposals to amend this RFC slightly to make the
additional parameter an
I think parts of this can easily be handled in zend_compile.
Other pieces requires runtime introspection that could be done at
zend_vm_def. My only concern is how to know what's the active scope
(class)...
While researching for data flow, I also saw that with the inclusion of AST,
some checks
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
Dear Internals,
I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If
accepted, methods with the same name as their defining class will no
longer be recognized as constructors. As noted in the RFC, there are
already many situations where we do not recognize these methods as
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,
I think that it is great time to end to PHP 4 constructors system for PHP 7.
IMO, It's a good RFC.
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison le...@php.net wrote:
Dear Internals,
I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If
accepted, methods with the same name as
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
Hi Andrea,
On Tue, Oct 21, 2014 at 7:57 AM, Andrea Faulds a...@ajf.me wrote:
I am presenting a new RFC to add a set of three functions to do validated
casts for scalar types:
https://wiki.php.net/rfc/safe_cast
I like this RFC overall. Precise parameter checks is good for security
always.
I
On 19 Nov 2014, at 03:02, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I would like to have DbC to harden app security as well.
I'm looking for something like D language.
http://dlang.org/contracts.html
With DbC, checking parameter types/range/etc happen only when development.
Therefore,
On Tue, Nov 18, 2014 at 3:26 PM, Julien Breux julien.br...@gmail.com
wrote:
I think that it is great time to end to PHP 4 constructors system for PHP
7.
IMO, It's a good RFC.
Agreed. I was going to suggest we throw E_DEPRECATED for 5.x, but you
already have that covered in the RFC. I
Hi all,
On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison le...@php.net wrote:
I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If
accepted, methods with the same name as their defining class will no
longer be recognized as constructors. As noted in the RFC, there are
already
45 matches
Mail list logo
