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
> 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
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
>> 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;
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
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
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: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!
> 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
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
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
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: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
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
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
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
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 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
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
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 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
>
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 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
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
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 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
>
> 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
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?
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
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 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
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!
> 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
>
> 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
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'
>
> 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
> 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 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
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!
> * 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
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
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
> 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
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
>
> 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,
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
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 c
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.
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
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
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 -
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 implementation
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 typed
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:
> *Nul
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.
55 matches
Mail list logo