Morning internals,
Since we have our answer on nullable types, typed properties can now go
to vote.
https://wiki.php.net/rfc/typed-properties#vote
Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.
Please
Afternoon internals,
The vote for typed properties has been restarted.
Please take part: https://wiki.php.net/rfc/typed-properties
Cheers
Joe
On 05/20/2016 08:05 AM, Joe Watkins wrote:
Morning internals,
Since we have our answer on nullable types, typed properties can now go
to vote.
https://wiki.php.net/rfc/typed-properties#vote
Note that, support for nullability as RFC'd will be merged when the
implementation for nu
On 20/05/16 07:05, Joe Watkins wrote:
> Morning internals,
>
> Since we have our answer on nullable types, typed properties can now go
> to vote.
>
> https://wiki.php.net/rfc/typed-properties#vote
>
> Note that, support for nullability as RFC'd will be merged when the
> implementatio
Joe, I fixed a minor typo in the RFC, hope you didn't mind. =)
On Fri, May 20, 2016 at 5:25 AM, Lester Caine wrote:
> On 20/05/16 07:05, Joe Watkins wrote:
> > Morning internals,
> >
> > Since we have our answer on nullable types, typed properties can now
> go
> > to vote.
> >
> > https:
y 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties
Morning internals,
Since we have our answer on nullable types, typed properties can now go
to vote.
https://wiki.php.net/rfc/typed-properties#vote
Note that, support for nullability a
. Dmitry.
From: Joe Watkins
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties
Morning internals,
Since we have our answer on nullable types, typed properties can now go
to vote
g if we have to perform
check on each read anyway.
Thanks. Dmitry.
From: Dmitry Stogov
Sent: Monday, May 23, 2016 11:30:09 AM
To: Joe Watkins; PHP internals; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
Hi Joe,
The performance eff
Hi!
> The performance effect of this implementation is terrible.
>
> Assignment to typed property is 2.3 times slower.
> Assignment to untyped property in a class with typed properties is 1.8 times
> slower.
>
> See the benchmark
> https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb80
Sent: Monday, May 23, 2016 11:30:09 AM
To: Joe Watkins; PHP internals; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
Hi Joe,
The performance effect of this implementation is terrible.
Assignment to typed property is 2.3 times slower.
Assignment to untyped property in a class
On Mon, May 23, 2016 at 11:09 AM, Stanislav Malyshev
wrote:
> Hi!
>
>> The performance effect of this implementation is terrible.
>>
>> Assignment to typed property is 2.3 times slower.
>> Assignment to untyped property in a class with typed properties is 1.8 times
>> slower.
>>
>> See the benchm
Morning internals,
I have improved the performance of the patch a little, here's the
results of a bad run:
krakjoe@fiji:/usr/src/php-src$ sapi/cli/php -n prop.php
empty_loop 0.064
write_prop1() 0.0880.025
write_prop2() 0.0790.016
write_prop3()
On 20/05/2016 07:05, Joe Watkins wrote:
Morning internals,
Since we have our answer on nullable types, typed properties can now go
to vote.
https://wiki.php.net/rfc/typed-properties#vote
Note that, support for nullability as RFC'd will be merged when the
implementation for nullable
rom: Joe Watkins
Sent: Monday, May 23, 2016 1:16:22 PM
To: Julien Pauli
Cc: Stanislav Malyshev; Dmitry Stogov; PHP internals; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
Morning internals,
I have improved the performance of the patch a little, here's the results
of a
20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties
Morning internals,
Since we have our answer on nullable types, typed properties can now go
to vote.
https://wiki.php.net/rfc/typed-properties#vote
Note that, support for nullability
ance of double, integer used in
> /home/dmitry/php/php-master/CGI-DEBUG/prop.php:6
>
Do you mean "float"?
>
>
> From: Joe Watkins
> Sent: Friday, May 20, 2016 9:05:34 AM
> To: PHP internals; Phil Sturgeon
> Subject: [PHP-
Yeah "float". It works :)
From: Niklas Keller
Sent: Monday, May 23, 2016 4:46:59 PM
To: Dmitry Stogov; Joe Watkins; PHP internals; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
Dmitry Stogov mailto:dmi...@zend.com>> schrieb
als; Phil Sturgeon
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
Morning internals,
I have improved the performance of the patch a little, here's the results
of a bad run:
krakjoe@fiji:/usr/src/php-src$ sapi/cli/php -n prop.php
empty_loop 0.064
wr
On May 23, 2016 4:09 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > The performance effect of this implementation is terrible.
> >
> > Assignment to typed property is 2.3 times slower.
> > Assignment to untyped property in a class with typed properties is 1.8
times slower.
> >
> > See the benchmark
, but we should agree on what
we are doing.
Thanks. Dmitry.
From: Joe Watkins
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties
Morning internals,
Since we have our answer on nullable types, typed properties can now go
> May be it's better to cancel voting, solve problems, finish the
> implementation and add missing questions into RFC...
> I'm going to help with implementation in any case, but we should agree on
> what we are doing.
>
> Thanks. Dmitry.
>
> _
m going to help with implementation in any case, but we should
agree on what we are doing.
Thanks. Dmitry.
From: Joe Watkins mailto:pthre...@pthreads.org>>
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeo
pen question if
>> "int $foo = NULL;" should be supported as nullable. Inheritance rules for
>> typed nullable properties are also missed.
>>
>> Personally, I think the RFC was moved into voting state too early
>> (without good enough implementation, and with missing topics).
>> The curre
), but still have unsolved problems.
May be it's better to cancel voting, solve problems, finish
the implementation and add missing questions into RFC...
I'm going to help with implementation in any case, but we
should agree on what we are doing.
Thanks.
escription of nullable properties.
>>> See tests Zend/tests/type_declarations/typed_properties_047.phpt,
>>> Zend/tests/type_declarations/typed_properties_048.phpt,
>>> Zend/tests/type_declarations/typed_properties_049.phpt
>>>
>>> I'm not sure
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 doesn't define how uninit
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,
>>
>>> I made this check(s) to be invariant.
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 can be expressed in the t
>
> 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 ...
> >
> >> RF
Wednesday, May 25, 2016 4:22:02 PM
To: Nikita Popov
Cc: Dmitry Stogov; PHP internals; Phil Sturgeon; Bob Weinand
Subject: 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, Ma
> 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 weird then
having di
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 mention that part ...
> RF
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.
And
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 cha
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
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 poten
> 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 $a;
>> public int $b;
>
>
> 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
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, since null
>>> isn'
>
> 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 se
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
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 ?Type
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,
pr
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 existing behavior her
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
de
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 else?
>
> 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 nulla
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
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 all type info / enforcem
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 typed properties, because t
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 retains its visibili
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 one after $this->var = nu
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 get an error after an
>
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, nulla
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 her
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. I
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
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;
pub
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 pre
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 $x
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 id
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 implementa
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
unse
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 a
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, nu
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
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 actu
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); // Fa
>> 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;
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 a
> 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 initialized. I'm conc
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); // except
2016-05-26 7:00 GMT+02:00 Stanislav Malyshev :
> 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 $
On 5/26/2016 12:03 AM, Stanislav Malyshev wrote:
> 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
Hi Dmitry,
>
> 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 initia
On 25/05/2016 22:03, Fleshgrinder wrote:
We already have the differentiation between IS_NULL and IS_UNDEF, why
not expose the latter to userland?
I wondered if the conversation would go in this direction. This has been
discussed to death, and in my opinion all the reasons given in previous
di
Have a look at my latest message:
http://marc.info/?l=php-internals&m=146424924029857&w=2
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
On 26/05/2016 08:52, Fleshgrinder wrote:
I understand where you are getting at. Another proposal after giving
this some more thought.
Could you summarise what your proposal actually is; I got a bit lost
with what your long list of examples was trying to show me.
Note that the behavior of i
On 5/26/2016 12:03 PM, Rowan Collins wrote:
> Could you summarise what your proposal actually is; I got a bit lost
> with what your long list of examples was trying to show me.
>
To summarize it: we should change the behavior of isset() to work
exactly the same way as it does for associative arra
On 26/05/2016 11:16, Fleshgrinder wrote:
$o = (object) ['x' => null];
var_dump(isset($a->x)); // false
var_dump(property_exists($a, 'x')); // true
Apart from a typo in your example (you change from $o to $a), this is
already the current behaviour, and always has been: https
On 5/26/2016 12:39 PM, Rowan Collins wrote:
> On 26/05/2016 11:16, Fleshgrinder wrote:
>> $o = (object) ['x' => null];
>> var_dump(isset($a->x)); // false
>> var_dump(property_exists($a, 'x')); // true
>
> Apart from a typo in your example (you change from $o to $a), this is
>
Bare with me ... just trying to fill in a few of the gaps in the current
documentation.
On 26/05/16 11:49, Fleshgrinder wrote:
> $g = new class { public $x; };
>
> var_dump(isset($g->x)); // false
isset manual entry does not say what happens if $g->x does not exist but
the false
On 5/26/2016 1:41 PM, Lester Caine wrote:
>> var_dump(property_exists($g, 'x')); // true
>
> or array_key_exists('x', $g) in our consistent style but as has been
> pointed out we do not have a simple 'exists' ...
> $g->exists('x') ?
> along with $g->isinit('x')
>
I like the exists() idea. :)
On 26/05/2016 11:49, Fleshgrinder wrote:
On 5/26/2016 12:39 PM, Rowan Collins wrote:
On 26/05/2016 11:16, Fleshgrinder wrote:
$o = (object) ['x' => null];
var_dump(isset($a->x)); // false
var_dump(property_exists($a, 'x')); // true
Apart from a typo in your example (you ch
On 5/26/2016 1:57 PM, Rowan Collins wrote:
> I am definitely in favour of this from a language point of view. The
> notice is warning about *initialization*, not *declaration*, so it makes
> sense to warn on "var $foo" and not "var $foo = null".
>
> The only thing I'm not sure is what the impact w
On 5/25/16 6:03 PM, Stanislav Malyshev wrote:
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 cl
On 5/25/16 5:52 PM, Thomas Bley wrote:
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); /
I think strict_types=1 should give a fatal error for accessing non-initialized
typed properties, instead of notice.
Example:
declare(strict_types=1);
class A {
public int $x;
public ?int $y = null;
public int $z = 42;
public ?int $u;
public ?datetime $v;
>
> If you want, you can easily write a backwards-compatible new class that
> uses declared type properties with
> public int $property = null;
And for those pesky third party libraries that forgot to set = NULL on
their property definition there's a backwards compatible accessor too.
$foo = $obj
On 5/26/16, 11:02 AM, "James Gilliland" wrote:
>Sarcasm aside, I still can't figure out how fundamentally changing how
>people interact with uninitialized properties like this improves
>developer experience. Can someone explain a case where this is better and
>catches a bug or something? Since th
The problem is a completely different one, how should the following code
behave?
class A {
public int $x;
}
(new A)->x;
The property has no value assigned but it is being accessed. The current
PHP behavior is to simply initialize it with null. But this is
impossible according to the
On 5/26/16, 12:30 PM, "Fleshgrinder" wrote:
>The problem is a completely different one, how should the following code
>behave?
>
> class A {
>
>public int $x;
>
> }
>
> (new A)->x;
>
>The property has no value assigned but it is being accessed. The current
>PHP behavior is to simply initia
Hi Thomas,
On the face of it, I'm not enthusiastic to introduce new magic numbers
(which would be false, 0, 0.0, "", and [], right?) that PHP assigns when
coercing a typed, uninitialized property read by a file in liberal mode.
This is like taking the most confusing thing about 7.0's dual-mode, s
On 26/05/2016 17:40, Tom Worster wrote:
0. Fatal error after __construct was called.
>1. Fatal error and abort.
>2. Initialize with appropriate type.
>3. Initialize with null.
Under another 5th option, the problem you state does not arise. Disallow
"public int $x;". Under this option you may dec
On 5/26/2016 6:40 PM, Tom Worster wrote:
> On 5/26/16, 12:30 PM, "Fleshgrinder" wrote:
>
>> The problem is a completely different one, how should the following code
>> behave?
>>
>> class A {
>>
>>public int $x;
>>
>> }
>>
>> (new A)->x;
>>
>> The property has no value assigned but it is b
On 26/05/2016 17:30, Fleshgrinder wrote:
class O {
public int $x;
}
echo (new O)->x; // null + E_NOTICE
As I'm sure has already been pointed out (I haven't followed the whole
thread) this defeats a large advantage of typed properties - I now can't
read from the property without chec
On 5/26/2016 6:50 PM, Rowan Collins wrote:
> As I'm sure has already been pointed out (I haven't followed the whole
> thread) this defeats a large advantage of typed properties - I now can't
> read from the property without checking if it's null, so I can't do this:
>
> class O {
>public \Date
On 5/26/16, 12:48 PM, "Fleshgrinder" wrote:
>>
>> Under another 5th option, the problem you state does not arise. Disallow
>> "public int $x;". Under this option you may declare $x with type int and
>> an initial value or you may declare $x without type but you may not
>> declare $x with type (n
On 5/26/2016 7:00 PM, Tom Worster wrote:
> On 5/26/16, 12:48 PM, "Fleshgrinder" wrote:
>> This would be a valid approach too, yes. I personally would be against
>> it because I do not want to initialize all my properties.
>>
>> class A {
>>
>>private int $x;
>>
>>public function getX() {
On 26/05/2016 17:57, Fleshgrinder wrote:
On 5/26/2016 6:50 PM, Rowan Collins wrote:
As I'm sure has already been pointed out (I haven't followed the whole
thread) this defeats a large advantage of typed properties - I now can't
read from the property without checking if it's null, so I can't do
1 - 100 of 235 matches
Mail list logo
