Zeev Suraski schrieb am Di., 17. Juli 2018, 00:10:
> > Based on the feedback we received, we have decided to target PHP 7.4 for
> this
> > RFC. A main factor for this decision was that the RFC requires some
> non-trivial
> > changes to 3rd-party extensions for full compatibility. This would put
>
Am 17.07.2018 um 07:35 schrieb Zeev Suraski:
On 17 Jul 2018, at 7:12, Levi Morrison wrote:
Fixing `array_slice` would probably do more harm than good at this
stage. Instead I would like to provide an alternative function that
does not have all this baggage, and will have decent performance much
On Tue, Jul 17, 2018 at 2:11 PM, Levi Morrison wrote:
> And another: `$length` is a length when it's a positive number, but
> it's an offset from the end when it's negative.
>
That's how substr() works, so it's at least consistent with that.
It makes a lot more sense if you think of it as
$arra
> On 17 Jul 2018, at 7:12, Levi Morrison wrote:
>
> Fixing `array_slice` would probably do more harm than good at this
> stage. Instead I would like to provide an alternative function that
> does not have all this baggage, and will have decent performance much
> of the time. The best ideas I ha
Le 13/07/2018 à 23:48, Zeev Suraski a écrit :
> So why not do both - remove these files from version control, but also update
> the re2c requirements in configure and makedist..?
>
> And of course we still want to bundle these in our distros - just not track
> them in our source control.
I agr
Recently I've been scrutinizing array_slice. It's been painful.
For instance, `$preserve_keys` is totally ignored for string keys.
This was undocumented until Christoph integrated it 2-3 days ago
(thanks, cmb). However, this is really not a good design decision: why
have a parameter that is called
Am 09.07.2018 um 13:16 schrieb Woortmann, Enno:
Hi,
as the discussion got no new contributions I'd like to start the
voting for the RFC fo add new functions for the handling of outer
array elements.
https://wiki.php.net/rfc/array_key_first_last
To have a better separation I split up the vo
On 16 July 2018 19:42:49 BST, Stanislav Malyshev wrote:
>Hi!
>
>> I agree with you. If someone really wants to have an "uninitialized"
>field
>> on purpose, they should do that using the correct type declaration,
>i.e.:
>>
>> ?MyType $myNullable = null;
>>
>> When this was started I asked if it
> Based on the feedback we received, we have decided to target PHP 7.4 for this
> RFC. A main factor for this decision was that the RFC requires some
> non-trivial
> changes to 3rd-party extensions for full compatibility. This would put the
> ongoing (but nearly complete) effort to port extensions
On Mon, Jul 16, 2018 at 3:45 PM, Nikita Popov wrote:
> Based on the feedback we received, we have decided to target PHP 7.4 for
> this RFC. A main factor for this decision was that the RFC requires some
> non-trivial changes to 3rd-party extensions for full compatibility. This
> would put the ongo
On 16.07.2018 at 21:45, Nikita Popov wrote:
> Based on the feedback we received, we have decided to target PHP 7.4 for
> this RFC. A main factor for this decision was that the RFC requires some
> non-trivial changes to 3rd-party extensions for full compatibility. This
> would put the ongoing (but
Hi!
I need help from somebody who knows how to deal with the details of
Apache2 bucket brigade API for some issue in Apache2 SAPI. I suspect
there's a bug there that can lead to serious problems in certain
situations but not sure how to fix it because my knowledge of proper
ways to handle Apache2
On Wed, Jun 20, 2018 at 11:59 PM, Nikita Popov wrote:
> Hi internals,
>
> Bob and I would like to present a new typed properties proposal for your
> consideration:
>
> https://wiki.php.net/rfc/typed_properties_v2
>
> The proposal allows you to annotate properties with types, which are
> enfor
Hi!
> I agree with you. If someone really wants to have an "uninitialized" field
> on purpose, they should do that using the correct type declaration, i.e.:
>
> ?MyType $myNullable = null;
>
> When this was started I asked if it was possible to check types right after
> object has been construct
On Monday, July 16, 2018 12:23:42 PM CDT Zeljko Mitic wrote:
> On Mon, Jul 16, 2018 at 1:42 PM Rowan Collins
>
> wrote:
> > On 16 July 2018 at 12:06, Arvids Godjuks wrote:
> >> Basically, you went wrong when you proposed a switch that controlls
> >> language behavior. To add to that - a switch t
On Mon, Jul 16, 2018 at 1:42 PM Rowan Collins
wrote:
> On 16 July 2018 at 12:06, Arvids Godjuks wrote:
>
>> Basically, you went wrong when you proposed a switch that controlls
>> language behavior. To add to that - a switch that probably is not
>> controllable by code that is running.
>>
>
>
> W
On Mon, Jul 9, 2018 at 10:47 AM, Nikita Popov wrote:
> Hi,
>
> I would like to start voting on the "Deprecation for PHP 7.3" RFC, which
> combines six minor deprecation proposals:
>
> https://wiki.php.net/rfc/deprecations_php_7_3
>
> Each deprecation is voted separately and will require a 2/3 maj
On Mon, Jul 9, 2018 at 10:36 AM, Nikita Popov wrote:
> Hi,
>
> I would like to open the vote on the RFC for the deprecation (in PHP 7.3)
> and removal (in PHP 8.0) of case-insensitive constants.
>
> https://wiki.php.net/rfc/case_insensitive_constant_deprecation
>
> If you missed the discussion fo
On 16 July 2018 at 17:24, Wes wrote:
> It's more strict in the proposed rfc. In particular in java the error is
> allowed to propagate in the program, while here it won't be.
> In other words if ` $foo->aaa` is uninitialized, you are not allowed to
> do ` $baz->bbb = $foo->aaa`.
> In java that's
On 16 July 2018 at 17:20, Nikita Popov wrote:
> On Sat, Jul 14, 2018 at 3:09 PM, Rowan Collins
> wrote:
>
> If I have an instance $v of that class, I would expect to be able to
>> safely call $v->validFrom->getTimestamp(), but need to check for nulls
>> before doing the same with validTo. Under
It's more strict in the proposed rfc. In particular in java the error is
allowed to propagate in the program, while here it won't be.
In other words if ` $foo->aaa` is uninitialized, you are not allowed to do `
$baz->bbb = $foo->aaa`.
In java that's allowed, so in java null pointer deref can really
On Sat, Jul 14, 2018 at 3:09 PM, Rowan Collins
wrote:
> Hi all,
>
> As briefly mentioned, I think the approach to non-nullable types in the
> typed properties proposal needs more discussion, to make sure we're not
> repeating Tony Hoare's "billion-dollar mistake".
>
> For parameter hints, nullabi
On 16 July 2018 at 17:07, Wes wrote:
> This is definitely not as bad as the "billion dollar mistake" though. The
> error still happens, but in a different place.
>
That's exactly what happens in most languages, isn't it? An error happens
when you try to resolve a null reference, but by then it'
On Monday, July 16, 2018 9:55:31 AM CDT Rowan Collins wrote:
> On 16 July 2018 at 14:28, Marco Pivetta wrote:
> > These don't really need explicit tests in most cases, but rather static
> > analysis (currently happening via docblocks). Static analysis tools like
> > vimeo/psalm already pick this u
I agree with you. If someone really wants to have an "uninitialized" field
on purpose, they should do that using the correct type declaration, i.e.:
?MyType $myNullable = null;
When this was started I asked if it was possible to check types right after
object has been constructed, but they said i
On 16 July 2018 at 16:42, Marco Pivetta wrote:
> There are naturally 3 states in the engine:
>
> 1 - value set
> 2 - value not set (default `null`)
> 3 - undefined/uninitialised
>
> These have been around since 5.0 AFAIK.
>
"Undefined" and "uninitialised" are not the same state:
class A {
There are naturally 3 states in the engine:
1 - value set
2 - value not set (default `null`)
2 - undefined/uninitialised
These have been around since 5.0 AFAIK.
On Mon, 16 Jul 2018, 16:55 Rowan Collins, wrote:
> On 16 July 2018 at 14:28, Marco Pivetta wrote:
>
> > These don't really need e
On 16 July 2018 at 14:28, Marco Pivetta wrote:
> These don't really need explicit tests in most cases, but rather static
> analysis (currently happening via docblocks). Static analysis tools like
> vimeo/psalm already pick this up.
>
Then why do we need the type hints at all?
> I'd even be
On 16.07.2018 at 13:15, Yasuo Ohgaki wrote:
> What you need is DbC.
> It's more flexible and complete. It satisfies all of your needs and more.
> An issue is that DbC is not static code analysis tool friendly.
>
> https://wiki.php.net/rfc/introduce_design_by_contract
> https://wiki.php.net/rfc/db
These don't really need explicit tests in most cases, but rather static
analysis (currently happening via docblocks). Static analysis tools like
vimeo/psalm already pick this up.
I'd even be happy to get type hints that only have effect on
`ReflectionProperty#getType()` as a massive improvement ov
On 16 July 2018 13:00:57 BST, Dan Ackroyd wrote:
>On 16 July 2018 at 09:43, Rowan Collins
>wrote:
>
>> There's no contradiction here; throwing an error when a
>> property is *read* is not the same as enforcing that it always has a
>valid value.
>
>That's true, but claiming the RFC just 'trusts' t
On 16 July 2018 at 09:43, Rowan Collins wrote:
> There's no contradiction here; throwing an error when a
> property is *read* is not the same as enforcing that it always has a valid
> value.
That's true, but claiming the RFC just 'trusts' the users to
initialise them is a miss-representation of
On Mon, Jul 16, 2018 at 1:44 PM Zeljko Mitic wrote:
>
>
> On Mon, Jul 16, 2018 at 1:14 PM Nikita Popov wrote:
>
>> On Sun, Jul 15, 2018 at 9:39 PM, Zeljko Mitic wrote:
>>
>>> PHP is dynamic language and each typed typehinted parameter has to be
>>> checked every time. I am suggesting new php.in
On 16/07/18 12:14, Zeljko Mitic wrote:
But please, do keep in mind that I would like to have this feature as
optional.
The problem with most of these 'improvements' to PHP is that the case is
always made that 'you do not have to use it' and this is yet another
load on the code base that 'you
On Mon, Jul 16, 2018 at 1:14 PM Nikita Popov wrote:
> On Sun, Jul 15, 2018 at 9:39 PM, Zeljko Mitic wrote:
>
>> PHP is dynamic language and each typed typehinted parameter has to be
>> checked every time. I am suggesting new php.ini value "typecheck.enable =
>> 1" which can be turned off.
>>
>>
On 16 July 2018 at 12:06, Arvids Godjuks wrote:
> Basically, you went wrong when you proposed a switch that controlls
> language behavior. To add to that - a switch that probably is not
> controllable by code that is running.
>
While I agree with your general principle here, I would like to rai
пн, 16 июл. 2018 г. в 14:14, Zeljko Mitic :
>
>
> On Mon, Jul 16, 2018 at 1:06 PM Arvids Godjuks
> wrote:
>
>> пн, 16 июл. 2018 г. в 13:56, Zeljko Mitic :
>>
>>> I tried to, but I honestly can't see the problem. No decent programmer
>>> makes error by sending wrong type of parameter and this feat
On Mon, Jul 16, 2018 at 4:46 AM Zeljko Mitic wrote:
> PHP is dynamic language and each typed typehinted parameter has to be
> checked every time. I am suggesting new php.ini value "typecheck.enable =
> 1" which can be turned off.
>
> Example:
> with default php config, a code like this would chec
On Mon, Jul 16, 2018 at 1:06 PM Arvids Godjuks
wrote:
> пн, 16 июл. 2018 г. в 13:56, Zeljko Mitic :
>
>> I tried to, but I honestly can't see the problem. No decent programmer
>> makes error by sending wrong type of parameter and this feature is 100%
>> optional. I know for sure that even in my d
On Sun, Jul 15, 2018 at 9:39 PM, Zeljko Mitic wrote:
> PHP is dynamic language and each typed typehinted parameter has to be
> checked every time. I am suggesting new php.ini value "typecheck.enable =
> 1" which can be turned off.
>
> Example:
> with default php config, a code like this would che
пн, 16 июл. 2018 г. в 13:56, Zeljko Mitic :
> I tried to, but I honestly can't see the problem. No decent programmer
> makes error by sending wrong type of parameter and this feature is 100%
> optional. I know for sure that even in my dev computer, I would use this
> feature, and probably most pro
On Mon, Jul 16, 2018 at 12:56 PM Zeljko Mitic wrote:
> I tried to, but I honestly can't see the problem. No decent programmer
> makes error by sending wrong type of parameter and this feature is 100%
> optional. I know for sure that even in my dev computer, I would use this
> feature, and probabl
I tried to, but I honestly can't see the problem. No decent programmer
makes error by sending wrong type of parameter and this feature is 100%
optional. I know for sure that even in my dev computer, I would use this
feature, and probably most programmers aware of the issue.
Maybe simpler example:
On 16 July 2018 00:52:53 BST, Dan Ackroyd wrote:
>On 14 July 2018 at 14:09, Rowan Collins
>wrote:
>> Hi all,
>>
>> The current RFC proposes the next simplest solution, which is to
>allow non-nullable types, and trust the user to initialise them before
>use.
>
>
>From the RFC:
>> If a typed proper
Le vendredi 13 juillet 2018, 16:48:29 CEST Levi Morrison a écrit :
> Below is a proof-of-concept for the `array_offset` function [mentioned
> by Nicolas Grekas][2] (which by the way, neither the RFC author nor
> anyone else responded to this suggestion) that is simply a convenience
> wrapper over `
45 matches
Mail list logo
