Hi all,
On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison 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 many situatio
On Tue, Nov 18, 2014 at 3:26 PM, Julien Breux
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 don't see anything wro
> On 19 Nov 2014, at 03:02, Yasuo Ohgaki 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, app runs fas
Hi Andrea,
On Tue, Oct 21, 2014 at 7:57 AM, Andrea Faulds 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 would
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
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 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 their def
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
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
constructo
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
(
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 curr
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 opt
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
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 con
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
> 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
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 modif
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 wrote:
> yeah, the consensus was to create feature request on bugs.php.net for PRs
> (and link the PR from the bugtracker
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
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 n
> 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 in short would allow any method
>
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
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/
46 matches
Mail list logo
