Re: [PHP-DEV] [RFC][Vote] Typed Properties

I thought about a different approach :) - not-nullable typed properties must be explicitly initialized (or should be initialized implicitly by corresponding types, e.g. "int" should get default value int(0). ...) - nullable typed properties may be implicitly initialized by NULL (like untyped

Re: [PHP-DEV] [RFC][Vote] Typed Properties

> > On Wed, May 25, 2016 at 10:30 AM, Joe Watkins > wrote: > > > Morning Dmitry, > > > >> I made this check(s) to be invariant. You may like to do this > > differently... > > > >I think this is what everyone expects, isn't it ? > > > >I did omit to mention that

Re: [PHP-DEV] [RFC][Vote] Typed Properties

> On 25 May 2016, at 16:56, Dmitry Stogov wrote: > > - unset() of typed properties should not be allowed Potentially opening a larger can of worms: what is the use case of unsetting any declared property? Changing this would of course be a huge BC break but it seems less

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/16 9:03 AM, Nikita Popov wrote: On Wed, May 25, 2016 at 10:30 AM, Joe Watkins wrote: Morning Dmitry, > I made this check(s) to be invariant. You may like to do this differently... I think this is what everyone expects, isn't it ? I did omit to

[PHP-DEV] [RFC] Typed Properties On Hold

Morning internals, Since some important details regarding the recently accepted nullable types feature were missing from the RFC, the vote has been stopped for typed properties, while we resolve these issues and update the RFC, and implementation. Voting on the final implementation will

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi Niklas, Niklas Keller wrote: There is a difference between not set and no meaningful value. In PHP, there's no such difference for properties. And I think we should be consistent with the existing behavior here. That's not quite true, unset properties produce a notice when accessed,

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi! > Why do you say "now"? unset() has done this for a long time, so far as I > know. True. But I don't see how would it work for typed properties - what exactly would happen after unset? Would it be - as it is now - that it is as if the property was never defined, or would it be something

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/2016 8:01 PM, Stanislav Malyshev wrote: > Hi! > >> Why do you say "now"? unset() has done this for a long time, so far as I >> know. > > True. But I don't see how would it work for typed properties - what > exactly would happen after unset? Would it be - as it is now - that it > is as if

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi, Stanislav Malyshev wrote: wouldn't be inventing a new null, though, we'd be leaving the property undefined until it's initialised, which we already have support for (properties, and indeed all variables can be unset()). unset() now causes the property to disappear - as if it were never

Re: [PHP-DEV] [RFC][Vote] Typed Properties

> > Hey Niklas, > > > Am 25.05.2016 um 18:21 schrieb Niklas Keller : > > > >> > >> Hi Niklas, > >> > >> Niklas Keller wrote: > >> > >>> > >>> I disagree here. Properties are always null by default. The current > patch > >>> disallows > >>> access to uninitialized variables only

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/2016 11:29 PM, Stanislav Malyshev wrote: > OTOH, we do have precedent for properties that can not be unset - > namely, static properties can not be unset. They can be nulled-out, of > course, and they default to null. I have no idea how "static int $x;" > would work though. The current RFC

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Following "Type safety is the goal of this RFC, not validating objects.", it would be better to do implicit casting for uninitialized properties (whenever implicit casting is possible) or use null for nullable types: class A { public int $x; public ?int $y = null; public int $z = 42;

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/2016 11:37 PM, Stanislav Malyshev wrote: > Hi! > >> We already have the differentiation between IS_NULL and IS_UNDEF, why >> not expose the latter to userland? I mean, JavaScript has it too and >> people are able to understand it. > > IS_UNDEF is not a PHP type, it is an engine

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi! > var_dump($a->w); // Fatal error, uninitialized... This means every read access to a property should be checked for it being typed, and every access to a typed property should be checked for it being initialized. I'm concerned there might be a performance hit for this. Also, this means no

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi! > Andrea already said that we would not use it for untyped properties, > hence, no BC. Again, it's not that simple. Properties are not local. That means any code that can deal with a class that may have typed properties (which may be library class, for example, so you don't even know what it

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi! > We already have the differentiation between IS_NULL and IS_UNDEF, why > not expose the latter to userland? I mean, JavaScript has it too and > people are able to understand it. IS_UNDEF is not a PHP type, it is an engine implementation flag. Now, adding a new type "undefined" would be a

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/2016 11:35 PM, Thomas Bley wrote: > Following "Type safety is the goal of this RFC, not validating objects.", it > would be better to do implicit casting for uninitialized properties (whenever > implicit casting is possible) or use null for nullable types: > > class A { > public int

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 25/05/16 22:03, Fleshgrinder wrote: > We already have the differentiation between IS_NULL and IS_UNDEF, why > not expose the latter to userland? Is this not simply a mistake? The whole reason for null in my book is that it IS 'undefined'. We have to have a flag for it since you can't easily

Re: [PHP-DEV] [RFC][Vote] Typed Properties

I'm not seeing a problem here: class A { public int $x; public ?int $y = null; public int $z = 42; public ?int $u; public ?datetime $v; public datetime $w; } $a = new A; var_dump($a->x); // 0 + notice var_dump($a->y); // null var_dump($a->z); // 42 var_dump(isset($a->z)); // true

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 25/05/16 22:42, Fleshgrinder wrote: > It is not the same as null, very similar, but definitely not the same. > Think of it in DB terms: > > | table | > | - | > | id| > > SELECT name FROM table; > > That's not null, it's not defined (undefined, unset, ...). In other > words,

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 25/05/16 22:52, Thomas Bley wrote: > var_dump($a->z); // 42 > var_dump(isset($a->z)); // true > unset($a->z); $a->z does not exist at this point > var_dump(isset($a->z)); // false We know that isset is broken so if $a->z is null we also get false ... perhaps the 'fault' that isset does not

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Currently the rfc also checks the properties for being initialized. I think it's still faster than most userland implementations using __get() for type checks and parsing phpdoc for type information. Regards Thomas Stanislav Malyshev wrote on 25.05.2016 23:56: > Hi! > >> var_dump($a->w); //

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi! >> True. But I don't see how would it work for typed properties - what >> exactly would happen after unset? Would it be - as it is now - that it >> is as if the property was never defined, or would it be something else? >> > > In my opinion it should simply vanish along with its definition.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

2016-05-25 20:39 GMT+02:00 Fleshgrinder : > In my opinion it should simply vanish along with its definition. I mean, > Usually, yes. But suddenly `private Type $foo` isn't reliable anymore if unset is supported for typed properties, because the following would just remove

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Andrea Faulds schrieb am Mi., 25. Mai 2016 19:14: > Hi Niklas, > > Niklas Keller wrote: > >> > >> There is a difference between not set and no meaningful value. > >> > > > > In PHP, there's no such difference for properties. And I think we should > be > > consistent with the

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/2016 9:13 PM, Niklas Keller wrote: > 2016-05-25 20:39 GMT+02:00 Fleshgrinder : > >> In my opinion it should simply vanish along with its definition. I mean, >> > > Usually, yes. But suddenly `private Type $foo` isn't reliable anymore if > unset is supported for

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 25 May 2016 at 21:13, Niklas Keller wrote: > Unset can reset it to the default value, but wiping type information is > probably > not an option here. > Wiping type info is indeed unwanted. As it currently stands, for example, un-setting a property and then re-assigning it

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Morning Dmitry, There's no section for nullables, but there is mention of them, specifically in relation to your query: > While parameters allow null to be accepted as the default value, null is only a valid value for nullable properties. Is there something wrong with that rule ?

Re: [PHP-DEV] base64_decode is buggy, what to fix?

Thanks for all the comments. Update: - Null byte ends processing. - In strict mode, space between padding fails - In strict mode, after a padding, one character is skipped https://github.com/php/php-src/pull/1923 - Too short padding is allowed, e.g. "VV=" works like "VV==". - Extra padding

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/2016 5:49 PM, Andrea Faulds wrote: > PHP's existing untyped properties are implicitly initialised to null, > and so yes, we would essentially only be copying our existing behaviour. > > However, I think it is worth asking whether our existing behaviour is > useful before we preserve it

Re: [PHP-DEV] [RFC][Vote] Typed Properties

>> var_dump($a->z); // 0 + notice > The notice should be 'variable does not exist' as at this point $a->z > has no context at all! If we keep the private flag of a property after unset(), we should also keep the type of a property after unset(), e.g. class test { private $z = 42;

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Of course isset() has a special behaviour. So having some kind of real_isset() or initialized() would be nice. Regards Thomas Thomas Bley wrote on 26.05.2016 00:38: >>> var_dump($a->z); // 0 + notice >> The notice should be 'variable does not exist' as at this point $a->z >> has no context at

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 25/05/16 20:40, Fleshgrinder wrote: > In other words, unset is not really unset already! > > QED: Preserving *all* attributes of a property is the only consistent > way. However, preserving its value is not. > > I do not think that there is a problem together with the typed > properties,

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Le Wed, 25 May 2016 21:40:28 +0200, Fleshgrinder a écrit: and unset simply because the property is not explicitly assigned null by unset, it is being undefined. Because null !== undefined. That's why you get an error after an unset($this->var), and you don't get

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 5/25/2016 10:23 PM, Benoit Schildknecht wrote: > Le Wed, 25 May 2016 21:40:28 +0200, Fleshgrinder > a écrit: > >> and unset simply because the property is not >> explicitly assigned null by unset, it is being undefined. > > > Because null !== undefined. That's why you

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 05/25/2016 09:06 AM, Joe Watkins wrote: Morning Dmitry, There's no section for nullables, but there is mention of them, specifically in relation to your query: > While parameters allow null to be accepted as the default value, null is only a valid value for nullable properties.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

> Am 25.05.2016 um 23:56 schrieb Stanislav Malyshev : > > Hi! > >> var_dump($a->w); // Fatal error, uninitialized... > > This means every read access to a property should be checked for it > being typed, and every access to a typed property should be checked for > it being

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi! > Also, property access never was safe. Consider: > > $obj = new class { > public $foo; > function __construct() { > unset($this->foo); > } > function __get($prop) { > throw new Exception("No $prop for you today!"); > } > }; > var_dump($obj->foo); //

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On 05/25/2016 11:30 AM, Joe Watkins wrote: Morning Dmitry, > I made this check(s) to be invariant. You may like to do this differently... I think this is what everyone expects, isn't it ? I did omit to mention that part ... > RFC doesn't define how uninitialized nullable

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Morning Dmitry, > I made this check(s) to be invariant. You may like to do this differently... I think this is what everyone expects, isn't it ? I did omit to mention that part ... > RFC doesn't define how uninitialized nullable typed properties should behave. It does: >

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Morning Dmitry, > I suppose it should emit notice and return NULL. Yes, as untyped properties do (they would also invoke magic for unset, but defined property). > I'll change this as well (in an hour). Thanks ... Nullable property support was missing from the

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On Wed, May 25, 2016 at 10:30 AM, Joe Watkins wrote: > Morning Dmitry, > >> I made this check(s) to be invariant. You may like to do this > differently... > >I think this is what everyone expects, isn't it ? > >I did omit to mention that part ... > >> RFC

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Morning Nikita, That's pretty persuasive ... Dmitry, what are your thoughts on those points ? Cheers Joe On Wed, May 25, 2016 at 2:03 PM, Nikita Popov wrote: > On Wed, May 25, 2016 at 10:30 AM, Joe Watkins > wrote: > >> Morning Dmitry, >>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi, Nikita Popov wrote: On Wed, May 25, 2016 at 10:30 AM, Joe Watkins wrote: > *Nullable typed properties will not raise an exception when accessed before initialization.* I don't agree with this choice, for three reasons: a) This unnecessarily restricts what

[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-05-25

Results for project PHP master, build date 2016-05-25 06:28:00+03:00 commit: 2ae21ab previous commit:0cdbabe revision date: 2016-05-25 01:25:12+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] Quick introduction

Hi My name is Tomasz Siwiec wiki username "powerstce". I would like to join your community to be able to vote on the page. I hope this quick introduction will be enough to join. If you need more info please reply me back and I will provide required info. Thanks Tomasz Siwiec -- PHP Internals -

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi Niklas, Niklas Keller wrote: I disagree here. Properties are always null by default. The current patch disallows access to uninitialized variables only if they're not nullable, since null isn't a valid value then. I don't think having to explicitly set them to null is the think we want.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

> Am 25.05.2016 um 17:57 schrieb James Gilliland : > > This is a cool idea and continuation of the typing systems so I've been > sort of skimming this thread as its been discussed and this example and the > associated errors caught my attention. > >> class C { >> public

Re: [PHP-DEV] [RFC][Vote] Typed Properties

This is a cool idea and continuation of the typing systems so I've been sort of skimming this thread as its been discussed and this example and the associated errors caught my attention. > class C { > public $a; > public int $b; > public ?int $c; > } > $obj = new C; > Excuse me if this has

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hey Niklas, > Am 25.05.2016 um 18:21 schrieb Niklas Keller : > >> >> Hi Niklas, >> >> Niklas Keller wrote: >> >>> >>> I disagree here. Properties are always null by default. The current patch >>> disallows >>> access to uninitialized variables only if they're not nullable,

Re: [PHP-DEV] [RFC][Vote] Typed Properties

> > Hi Niklas, > > Niklas Keller wrote: > >> >> I disagree here. Properties are always null by default. The current patch >> disallows >> access to uninitialized variables only if they're not nullable, since null >> isn't a valid value then. >> >> I don't think having to explicitly set them to

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi! > * uninitialised - the constructor (or indeed, other code) is yet to set it > * null - the property is left intentionally empty For declared properties, this always has been the same, and I'm not sure why would we want to change that. This also has a potential to be a huge BC break if we

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi Stas, Stanislav Malyshev wrote: Hi! * uninitialised - the constructor (or indeed, other code) is yet to set it * null - the property is left intentionally empty For declared properties, this always has been the same, and I'm not sure why would we want to change that. This also has a

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Hi! > It'd be a BC break if we changed untyped properties' behaviour, yeah. We It's not that simple. Lots of code operates on sets of properties or dynamic properties, not one specific property. That code now assumes properties default to null. If there's another default, then all that code will

Re: [PHP-DEV] [RFC][Vote] Typed Properties

> > There is a difference between not set and no meaningful value. > In PHP, there's no such difference for properties. And I think we should be consistent with the existing behavior here. > The former is literally unset(), the latter is null. The only semantics > PHP exposes here is that not

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Since there are so many questions about nullable state (the default, in PHP), would it make sense to enforce nullable types, for now? Specifically, the current RFC could be simplified until further clarity is made on how non-nullability behaves: * we'd enforce users to always have `private