Hi!
> OK. In my opinion, if something is defined as "int" should be always
> "int". Nor "null" neither "undefined".
> This is good for programmers who think like me, for compiler and for
> hardware CPU :)
I understand why it's good, and I agree. The harder question is whether
we can deliver on
On 04/19/2016 10:53 PM, Stanislav Malyshev wrote:
Hi!
More properly - PHP is done in a way that doesn't allow big data
processing yet :)
LuaJIT may be used for in-kernel packet filtering...
But we're not targeting PHP for in-kernel packet filtering. And we
should not sacrifice language
Hi!
> More properly - PHP is done in a way that doesn't allow big data
> processing yet :)
>
> LuaJIT may be used for in-kernel packet filtering...
But we're not targeting PHP for in-kernel packet filtering. And we
should not sacrifice language semantics for minuscule gains in
performance.
On 04/18/2016 09:37 PM, Stanislav Malyshev wrote:
Hi!
right.
I don't see any reasons for types, if they are not guaranteed anyway.
Well, we already have parameter types, and they are not guaranteed
either - you can reassign variables.
They guarantee the type of argument on function entry.
Hi!
> right.
> I don't see any reasons for types, if they are not guaranteed anyway.
Well, we already have parameter types, and they are not guaranteed
either - you can reassign variables.
> This depends on use case.
> Just imagine matrix multiplication (or something similar).
> Few additional
On 04/15/2016 11:07 PM, Stanislav Malyshev wrote:
Hi!
In most cases we avoid IS_UNDEF checks, verifying the most probable expected
types first.
But that's for something like ADD, not for property fetches, so I'm not
sure I understand how properties fit there yet. Does the optimization
also
Hi!
> In most cases we avoid IS_UNDEF checks, verifying the most probable expected
> types first.
But that's for something like ADD, not for property fetches, so I'm not
sure I understand how properties fit there yet. Does the optimization
also track the variable after fetching?
In any case,
___
From: Stanislav Malyshev <smalys...@gmail.com>
Sent: Thursday, April 14, 2016 20:26
To: Dmitry Stogov; Joe Watkins
Cc: internals; Zeev Suraski; Nikita Popov
Subject: Re: [PHP-DEV] Re: Typed properties patch
Hi!
> I didn't understand.
> Of course we keep a class definition,
Hi!
> I didn't understand.
> Of course we keep a class definition, where the type of property "$a" -
> IS_LONG, but the actual value of "$a" may become IS_UNDEF.
What I'm saying is maybe it's fine.
> In PHP-7 we check for IS_LONG without type hint.
> With type hint and ability to unset(), we
On 04/13/2016 10:31 PM, Stanislav Malyshev wrote:
Hi!
Because if you unset() a property it's type is not guaranteed anymore.
Can't we fix it? I mean, when we unset property on an object, we're
still keeping the definition in the class, right? Can't we use it?
I didn't understand.
Of course
Hi!
> Because if you unset() a property it's type is not guaranteed anymore.
Can't we fix it? I mean, when we unset property on an object, we're
still keeping the definition in the class, right? Can't we use it?
>
> class Foo () {
> int $a = 0;
> }
> $a = new Foo();
> $b = $a->x + 5; /* we
ct: Re: [PHP-DEV] Re: Typed properties patch
Hi,
Unsetting properties is used by a range of libraries I am aware of, including
Doctrine (actually any project that relies on proxy generation).
Breaking this "feature" would be a catastrophe to a lot of projects.
There is an alternative tho
Hi,
Unsetting properties is used by a range of libraries I am aware of,
including Doctrine (actually any project that relies on proxy generation).
Breaking this "feature" would be a catastrophe to a lot of projects.
There is an alternative though, which would help: property getter/setter
would
On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:
Hi!
Thanks for your time reviewing the patch, appreciated.
> 1) nullable properties
I agree that we need a way to that, but I would rather see it
covered by nullable types rfc.
I think this is an attempt to achieve more type
Hi!
> Thanks for your time reviewing the patch, appreciated.
>
> > 1) nullable properties
>
> I agree that we need a way to that, but I would rather see it
> covered by nullable types rfc.
I think this is an attempt to achieve more type safety than even fully
typed languages like
On 06/04/16 10:19, Joe Watkins wrote:
> > 1) nullable properties
>
> I agree that we need a way to that, but I would rather see it
> covered by nullable types rfc.
>
> > 2) concerns about default values
>
> Implicit defaults would only allow us to reduce read checks, it
> can't
16 matches
Mail list logo
