On 03/30/2016 08:13 AM, Joe Watkins wrote:
Morning Dmitry,
So, I quickly reviewed the RFC and patch.
Static properties, and mixed declarations, are now explained in the RFC.
Thanks. I'm not agree with decisions, but RFC is more complete now.
It would be great to have "static" typed
On 03/30/2016 07:26 AM, Joe Watkins wrote:
Morning Pieere, Dmitry, all ...
Actually it's not so simple ... for object properties we have
ASSIGN_OBJ opcode, but we don't have a special opcode for static
properties, and ASSIGN doesn't have any information about where the
var came from, and no
On 03/30/2016 06:16 AM, Joe Watkins wrote:
Morning Dmitry,
> 1) static typed properties are prohibited. why?
Feels like that's a separate feature, static properties are as good as
makes no difference, global variables.
From the user perspective there is not a lot of difference between
reg
Morning Dmitry,
So, I quickly reviewed the RFC and patch.
Static properties, and mixed declarations, are now explained in the RFC.
I made a couple of changes to the fetch_obj_w stuff, I'd be grateful if
you could review that ... I didn't think I had got all possible
combinations, sho
Morning Pieere, Dmitry, all ...
Actually it's not so simple ... for object properties we have ASSIGN_OBJ
opcode, but we don't have a special opcode for static properties, and
ASSIGN doesn't have any information about where the var came from, and nor
should it have that information ...
I'm going t
On Mar 30, 2016 10:17 AM, "Joe Watkins" wrote:
>
> Morning Dmitry,
>
> > 1) static typed properties are prohibited. why?
>
> Feels like that's a separate feature, static properties are as good as
> makes no difference, global variables.
>
> Instance properties, the engine has good control over the
Actually, static properties are probably simpler than I thought ... I'm
still not sure about them though ...
I'd like to hear what others thing about static properties having types ...
Cheers
Joe
On Wed, Mar 30, 2016 at 4:16 AM, Joe Watkins wrote:
> Morning Dmitry,
>
> > 1) static typed proper
Morning Dmitry,
> 1) static typed properties are prohibited. why?
Feels like that's a separate feature, static properties are as good as
makes no difference, global variables.
Instance properties, the engine has good control over their manipulation,
for static properties it doesn't, it's not imp
On Tue, Mar 29, 2016 at 5:16 PM, Levi Morrison wrote:
> > 2) The handling of multiple properties in the same declaration statement
> is inconsistent.
> >
> > public int $bar, string $qux; // this works
> >
> > public int $bar, $qux; //this emits error: Untyped property
> A::$qux m
> 2) The handling of multiple properties in the same declaration statement is
> inconsistent.
>
> public int $bar, string $qux; // this works
>
> public int $bar, $qux; //this emits error: Untyped property A::$qux
> must not be mixed with typed properties
>
> It's better to allow
Hi,
Reviewing the patch sources I found few inconsistent decisions not mentioned in
RFC.
1) static typed properties are prohibited. why?
2) The handling of multiple properties in the same declaration statement is
inconsistent.
public int $bar, string $qux; // this works
publ
Hi internals!
Currently, inside instance methods the following invariant holds:
assert(is_null($this) || is_object($this))
This is a problem. I'd like to guarantee the following invariant instead:
assert(is_null($this) || $this instanceof self)
That is, ensure that if $this is not null
On Tue, Mar 29, 2016 at 2:58 PM, Björn Larsson
wrote:
> Den 2016-03-29 kl. 17:32, skrev Phil Sturgeon:
>>
>> I'd like to thank everyone for their feedback on this RFC!
>>
>> It looks like the majority of concerns were solved during the course
>> of this discussion, which is great news.
>>
>> The R
Den 2016-03-29 kl. 17:32, skrev Phil Sturgeon:
I'd like to thank everyone for their feedback on this RFC!
It looks like the majority of concerns were solved during the course
of this discussion, which is great news.
The RFC has been expanded in a few areas to take care of a few other
concerns,
Hi - I’m currently the maintainer of facebook/xhp-lib; as XHP’s been mentioned
a few times here, if someone’s interested in making a PHP7 version:
- while I won’t be able to directly work on a PHP7 port, I’ll be happy to help
in any other way (eg any questions about design/decisions)
- the mai
I have added some feedback and assigned it to myself ;)
On Tue, Mar 29, 2016 at 3:05 PM, Tom Worster wrote:
> mathieuk has requested feedback on a patch to mitigate this problem in PHP.
>
> https://bugs.php.net/bug.php?id=71915
>
> Tom
>
>
>
Thanks. I'll start tomorrow morning and will try to send you update by the
evening,
From: Joe Watkins
Sent: Tuesday, March 29, 2016 19:18
To: Dmitry Stogov
Cc: Phil Sturgeon; krak...@php.net; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC Discussion] Typed P
Hi Dmitry,
The patch is pretty close to complete.
When you start to dig a bit further, you'll notice that I prepared for
using cached pointers to prop info, but, I'm not sure how to allocate those
as the handlers are using the currently allocated slots so differently.
I also patched
Hi Phil, hi Joe,
Is your patch complete?
I took just a brief review yet, and I would like to make a deep check once
again (and may be optimization).
I saw, the patch makes some slowdown, but less than I expected.
If you are not going to modify the patch in next two days, I would start
working o
I'd like to thank everyone for their feedback on this RFC!
It looks like the majority of concerns were solved during the course
of this discussion, which is great news.
The RFC has been expanded in a few areas to take care of a few other
concerns, so please go and review it and let me know if you
mathieuk has requested feedback on a patch to mitigate this problem in PHP.
https://bugs.php.net/bug.php?id=71915
Tom
Hey Internals,
I have been thinking about / working on a couple of session improvements.
This work started once I had the time to fully read the "Precise session data
management" RFC.
I was thinking about creating small and specific RFCs for specific issues to be
discussed. I planned to put this
Hi all,
Security related changes in session module tends to take looong time
even if issue is serious security threat.
An example is adoptive session manager issue. Accepting user specified
(i.e. not generated by session manger) session ID allows attacker to
hijack session permanently, very easil
Hi all,
On Mon, Mar 28, 2016 at 9:23 PM, Chris Riley wrote:
> You are right, perhaps this should be controlled simply by an ini flag:
> session https only.
>
>
> On Mon, 28 Mar 2016, 01:09 Stanislav Malyshev, wrote:
>>
>> Hi!
>>
>> >> Could we also add HTTPS detection and enable the secure flag
Results for project PHP master, build date 2016-03-29 06:39:37+03:00
commit: 34d8fea
previous commit:a3f0add
revision date: 2016-03-28 11:55:03+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
25 matches
Mail list logo
