On 16 March 2016 at 09:36, Phil Sturgeon wrote:
> 3. Weak vs Strict. Right now this is entirely strict, with no
> declare() to change mode. Reasons for this vary, from various sources,
> but include "Not sure how to implement it" and "Well people should not
> be using properties as part of their p
What about PDO's fetch-mode PDO::FETCH_CLASS? Apparently, it first fills in
properties and then calls the constructor. Seems unlikely that the new
behavior for uninitialized properties will cause a problem here, but
sometimes weird things happen. And this is another thing to check.
I also fully sup
We have a bit of a problem with how Linux handles huge pages when you
run out of them.
I've been discussing it with Dmitry and he recently committed a way to
disable Huge Pages in the main allocator to master:
https://github.com/php/php-src/commit/945a661912612cdecd221cd126feda7d4335c33c
Hi,
On 16/03/16 16:36, Phil Sturgeon wrote:
2. This whole temporary nullability situation, where unset properties
will error on attempted usage if not set. Should they instead error
after the constructor has been called if they are still not holding a
value?
I'd have the error at the time of a
To answer my own question: the entire RFC is a no-go in its current state.
On 18 March 2016 at 10:09, Marco Pivetta wrote:
> That said, I have a few quite common use-cases that arise and that are a
> bit problematic, both because they are hacks and because they are actually
> used in large projec
On 3/17/2016 9:03 AM, Benjamin Eberlei wrote:
> Sorry to dampen your enthusiasm, but you are going slightly off topic here.
> Package visibility was tried by Guilherme Blanco before, the way namespaces
> are implemented this is not possible in PHP in an easy way. As far as i
> understood him, its w
Hi everyone,
I previously opened voting on the "Warn about invalid strings in
arithmetic" RFC, but I had to cancel it because of the issue of
inconsistent handling of scientific notation strings.
Since then, the RFC has been updated to deal with that issue. This has
meant that the RFC no lon
On 16 March 2016 at 17:17, Bob Weinand wrote:
> Hey, thank you both for investing your time :-)
> Property types are definitely interesting.
>
> > Am 16.03.2016 um 17:36 schrieb Phil Sturgeon :
> >
> > Hello everyone,
> >
> > I have completed the draft for an RFC, to add Typed Properties. The
> >
Just an idea of a syntax for nullable properties. What about:
/**
* Can be null
*/
public int null $foo;
/**
* Can NOT be null
*/
public float $bar;
This type of syntax has a long-living predecessor - SQL (INT NULL). I think
it is readable and it does not introduce ambiguity as in string|null
> On 16.03.2016, at 21:38, Anatol Belski wrote:
>
> Hi,
>
>> -Original Message-
>> From: David Zuelke [mailto:d...@heroku.com]
>> Sent: Tuesday, March 15, 2016 11:58 PM
>> To: Anatol Belski
>> Cc: Christoph Becker ; Pierre Joye
>> ; PHP internals
>> Subject: Re: [PHP-DEV] PCRE JIT stac
> Am 16.03.2016 um 18:39 schrieb Johannes Schlüter :
>
> On Wed, 2016-03-16 at 12:36 -0400, Phil Sturgeon wrote:
>> Hello everyone,
>>
>> I have completed the draft for an RFC, to add Typed Properties. The
>> patch has been written by the one and only Joe Watkins.
>>
>> https://wiki.php.net/rfc
On 3/16/16 5:16 PM, Sara Golemon wrote:
On Wed, Mar 16, 2016 at 2:58 PM, Stanislav Malyshev wrote:
Pretty basic RFC: There's new methods in ICU 52, wrap 'em up and make
'em available.
Note that despite these APIs being windows focused, they are in fact
available on Linux.
They're just a databas
Thanks for the feedback Patrick :-) I understand your concern. I added a
section to the RFC Impact section to mention that PHP tools/IDE will
require some modifications. Feel free to add some additional details in
this section if you want. People who will vote will then be aware of the
situation an
I had to open another PR, because the old one was accidentaly merged and
reverted.
https://github.com/php/php-src/pull/1825
I've also simplified specialization conditions a bit and started to use
ZVAL_LONG() instead of ZVAL_COPY_VALUE(), as Bob and Xinchen suggested.
Thanks. Dmitry.
Hi,
Fleshgrinder wrote:
On 3/16/2016 5:36 PM, Phil Sturgeon wrote:
2. This whole temporary nullability situation, where unset properties
will error on attempted usage if not set. Should they instead error
after the constructor has been called if they are still not holding a
value?
I see a bi
Hi Lin,
Lin Yo-An wrote:
Since the original approach doesn't work, here comes another new idea:
When executing method call on an object, if we found the method body are
just 2 op codes (FETCH_OBJ_R and RETURN), we then denote the method is a
"getter method"
And the next time, when we execute t
Hi,
On Thu, Mar 17, 2016 at 1:02 PM, Matt Prelude wrote:
I'd support borrowing the "?" nullable annotation from HackLang for
> people who want a less strict behavior:
>
> public ?string $name;
>
> This means that $name can either be a string or the NULL value.
>
Or, do it like with parameter ty
Hi,
> -Original Message-
> From: David Zuelke [mailto:d...@heroku.com]
> Sent: Tuesday, March 15, 2016 11:58 PM
> To: Anatol Belski
> Cc: Christoph Becker ; Pierre Joye
> ; PHP internals
> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>
> Sure. So composer creates patterns to parse a
Hello everyone,
PHP 5.6.20 RC1 was just released and can be downloaded from:
http://downloads.php.net/~tyrael/
The Windows binaries are available at http://windows.php.net/qa/
This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer
Hi,
On Thu, Mar 17, 2016 at 8:46 PM, Andrey Andreev wrote:
> I'd support borrowing the "?" nullable annotation from HackLang for
>> people who want a less strict behavior:
>>
>> public ?string $name;
>>
>> This means that $name can either be a string or the NULL value.
>>
>
> Or, do it like with
Hi,
PHP 7.0.5 RC1 was just released and can be downloaded from:
https://downloads.php.net/~ab/
The Windows binaries are available at
http://windows.php.net/qa/
This release contains a number of bugfixes.
For the list of bugfixes that you can target in your testing, please refer
to the
On Wed, 2016-03-16 at 18:50 +0100, Bob Weinand wrote:
> The patch currently prevents that.
> It prevents all creation of references to properties.
To all properties? Thus
class C {
private $data = []; // No type, old code
public function sort() {
sort($this->data);
}
}
won't work anym
Hi all,
On Thu, Mar 17, 2016 at 2:57 AM, Fleshgrinder wrote:
> On 3/15/2016 11:02 PM, Yasuo Ohgaki wrote:
>> Hi Scott,
>>
>> On Wed, Mar 16, 2016 at 2:40 AM, Scott Arciszewski
>> wrote:
>>> Question: If this extension is adopted, which syntax would you prefer?
>>>
>>> \Sodium\func()
>>>
Hi,
Le 16/03/2016 17:36, Phil Sturgeon a écrit :
Hello everyone,
I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.
https://wiki.php.net/rfc/typed-properties
Maybe you can add a reference to a discussion we had some mo
> Am 16.03.2016 um 19:41 schrieb Johannes Schlüter :
>
> On Wed, 2016-03-16 at 19:15 +0100, Bob Weinand wrote:
>>
>> Eih, only to typed properties. Everything else would be insane ;-)
>> Sorry for being imprecise.
>
> Ok, quite a lot better, but still weird difference to the language.
>
>
> T
On Wed, 2016-03-16 at 19:15 +0100, Bob Weinand wrote:
>
> Eih, only to typed properties. Everything else would be insane ;-)
> Sorry for being imprecise.
Ok, quite a lot better, but still weird difference to the language.
There's a notable amount of places where references are being used and
o
On 3/16/16 2:30 PM, Andrey Andreev wrote:
Also, a LOT of code would end up with e.g. a default value of 0 for an
integer property, still having to check if it was properly populated
with a positive value - not much of an improvement over NULLs. Cheers,
Andrey.
That's fine. Type checking doe
Awesome feature thanks for the RFC. :)
On 3/16/2016 5:36 PM, Phil Sturgeon wrote:
> 1. How scared are we that integers can be expanded to floats on runtime?
>
This is already what happens in PHP all the time and I personally only
see harm if we change that. People are already not understand what
On Wed, Mar 16, 2016 at 10:47 PM, Fleshgrinder wrote:
> On 3/16/2016 10:12 PM, Björn Larsson wrote:
> > Like the RFC :)
> >
> > Could this be an opportunity to have default visibility for property's
> when
> > they are typed in a similar fashion like for functions? Meaning no
> > visibility
> > i
Hi all,
On Thu, Mar 17, 2016 at 8:30 AM, Johannes Schlüter
wrote:
> On Wed, 2016-03-16 at 15:29 -0400, Phil Sturgeon wrote:
>> > What's expected here:
>> >
>> > class A {
>> > public int $i;
>> > }
>> >
>> > $a = new A();
>> > $r = &$a->i;
>> > $r = "foobar";
>
>> I put your code into 3v4l so y
On 19/03/16 12:31, Fleshgrinder wrote:
>>> You are mixing to things like I did. If you never unset and never assign
>>> >> then the value of the property is *null* or as I defined to avoid
>>> >> confusion *void*. All fine. The question was, should this result in an
>>> >> error and the general con
Hey, thank you both for investing your time :-)
Property types are definitely interesting.
> Am 16.03.2016 um 17:36 schrieb Phil Sturgeon :
>
> Hello everyone,
>
> I have completed the draft for an RFC, to add Typed Properties. The
> patch has been written by the one and only Joe Watkins.
>
> h
On Wed, Mar 16, 2016, at 11:36 AM, Phil Sturgeon wrote:
> Hello everyone,
>
> I have completed the draft for an RFC, to add Typed Properties. The
> patch has been written by the one and only Joe Watkins.
>
> https://wiki.php.net/rfc/typed-properties
>
> I would really appreciate constructive f
On 3/19/2016 12:51 PM, Fleshgrinder wrote:
> Moving this to a new thread in order to not spam the other.
>
> On 3/19/2016 11:48 AM, Fleshgrinder wrote:
>> On 3/19/2016 11:38 AM, Björn Larsson wrote:
>>> Den 2016-03-18 kl. 21:12, skrev Fleshgrinder:
No worries you are not, not at all. I just wa
Den 2016-03-19 kl. 13:29, skrev Fleshgrinder:
On 3/19/2016 1:19 PM, Björn Larsson wrote:
Hi,
There is "references" in the message header so it ends up in the
same thread in Thunderbird newsreader but with a new headline.
In case you want to repost...
I think it's a good starting point though,
On 3/19/2016 1:29 PM, Lester Caine wrote:
> On 19/03/16 12:17, Fleshgrinder wrote:
>> You are mixing to things like I did. If you never unset and never assign
>> then the value of the property is *null* or as I defined to avoid
>> confusion *void*. All fine. The question was, should this result in
On 19/03/16 12:17, Fleshgrinder wrote:
> You are mixing to things like I did. If you never unset and never assign
> then the value of the property is *null* or as I defined to avoid
> confusion *void*. All fine. The question was, should this result in an
> error and the general consensus here is /n
On 3/19/2016 12:23 PM, Lester Caine wrote:
> On 19/03/16 11:02, Fleshgrinder wrote:
Properties need the ability to be void even after construction and it is
>> up to the object to keep track and ensure state. Nullability is imho not
>> necessary at all. So we are all in line here.
> Am 16.03.2016 um 19:05 schrieb Johannes Schlüter :
>
> On Wed, 2016-03-16 at 18:50 +0100, Bob Weinand wrote:
>> The patch currently prevents that.
>> It prevents all creation of references to properties.
>
> To all properties? Thus
>
> class C {
> private $data = []; // No type, old code
>
First a general note on the complete nullability first: It is not up to
us as language designers to decide whether it is good practice to use
nullable properties or not. It is supported by many systems since ages
(e.g. SQL where nullable fields are also not recommended but heck they
are useful) and
On 18/03/16 10:55, Yasuo Ohgaki wrote:
>> Although I'm all for limiting NULL to only being the default value:
>> >
>> > $this->name = null; // this should throw a TypeError
> NULL is special type. '' and NULL is different entity.
>
> class User {
> public string $username = NULL;
> }
>
> Af
Moving this to a new thread in order to not spam the other.
On 3/19/2016 11:48 AM, Fleshgrinder wrote:
> On 3/19/2016 11:38 AM, Björn Larsson wrote:
>> Den 2016-03-18 kl. 21:12, skrev Fleshgrinder:
>>> No worries you are not, not at all. I just wanted to thwart you and
>>> others in directly assig
Hello Everyone,
I am recently trying to write an optimizer that could optimize the getter
method call into just one object fetch opcode.
I'd like to know thoughts from you guys, here is the note:
https://c9s.hackpad.com/INLINE-OP-TVGo9WcshbZ
--
Best Regards,
Yo-An Lin
https://github.com/c9s
On 19/03/16 11:02, Fleshgrinder wrote:
>>> Properties need the ability to be void even after construction and it is
>>> >> up to the object to keep track and ensure state. Nullability is imho not
>>> >> necessary at all. So we are all in line here.
>> >
>> > If the record I am working with identif
Results for project PHP master, build date 2016-03-16 06:31:01+02:00
commit: 4165ae1
previous commit:4739196
revision date: 2016-03-15 22:19:01+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Thu, Mar 17, 2016 at 12:23 AM, Phil Sturgeon
wrote:
> > Yet, your argument was about avoiding is_null() calls within application
> > logic and you'd gain nothing if you end up having to write ! empty()
> > instead. :)
> > I'd rather have a NULL to tell me that I have nothing instead of a
> > s
On Wed, 2016-03-16 at 15:29 -0400, Phil Sturgeon wrote:
> > What's expected here:
> >
> > class A {
> > public int $i;
> > }
> >
> > $a = new A();
> > $r = &$a->i;
> > $r = "foobar";
> I put your code into 3v4l so you could see what would happen:
>
> https://3v4l.org/taC8D
>
> Fatal error: Unc
On 3/19/2016 11:54 AM, Lester Caine wrote:
> On 19/03/16 10:23, Fleshgrinder wrote:
>> Properties need the ability to be void even after construction and it is
>> up to the object to keep track and ensure state. Nullability is imho not
>> necessary at all. So we are all in line here.
>
> If the re
Hi,
On Wed, Mar 16, 2016 at 9:21 PM, Ryan Pallas wrote:
> On Wed, Mar 16, 2016 at 12:50 PM, Larry Garfield
> wrote:
>
> > On 3/16/16 11:36 AM, Phil Sturgeon wrote:
> >
> >>
> >> 2. This whole temporary nullability situation, where unset properties
> >> will error on attempted usage if not set.
On 19/03/16 10:23, Fleshgrinder wrote:
> Properties need the ability to be void even after construction and it is
> up to the object to keep track and ensure state. Nullability is imho not
> necessary at all. So we are all in line here.
If the record I am working with identifies elements are incor
On 3/19/2016 11:38 AM, Björn Larsson wrote:
> Den 2016-03-18 kl. 21:12, skrev Fleshgrinder:
>> No worries you are not, not at all. I just wanted to thwart you and
>> others in directly assigning ...
>>
>> final class A {
>> int $x;
>> }
>>
>> ... to be *public* and obstruct the o
On 19/03/16 05:20, Walter Parker wrote:
>> C A Horte, the famous computer scientist, calls the introduction of nulls
> into his type system (like how Java did it decades later) to be his Billion
> dollar mistake. He did it for the mathematical elegance and didn't foresee
> all of the null errors th
On Wed, Mar 16, 2016 at 5:36 PM, Phil Sturgeon wrote:
> Hello everyone,
>
> I have completed the draft for an RFC, to add Typed Properties. The
> patch has been written by the one and only Joe Watkins.
>
> https://wiki.php.net/rfc/typed-properties
>
> I would really appreciate constructive feedba
Den 2016-03-18 kl. 21:12, skrev Fleshgrinder:
On 3/17/2016 9:03 AM, Benjamin Eberlei wrote:
Sorry to dampen your enthusiasm, but you are going slightly off topic here.
Package visibility was tried by Guilherme Blanco before, the way namespaces
are implemented this is not possible in PHP in an ea
On 3/19/2016 5:04 AM, Larry Garfield wrote:
> On 03/18/2016 03:49 PM, Fleshgrinder wrote:
>> First a general note on the complete nullability first: It is not up to
>> us as language designers to decide whether it is good practice to use
>> nullable properties or not. It is supported by many system
On 3/18/2016 11:10 PM, Dennis Birkholz wrote:
> Hi all,
>
> Am 16.03.2016 um 21:29 schrieb Fleshgrinder:
>> Another more complicated user case would be *mysqli_fetch_object* that
>> populates the properties with values from a storage but values that
>> should become something specific and strict a
Morning Lee,
> Makes sense. AccessTypeError, WriteTypeError to both extend TypeError?
Well maybe ... I'm not sure there is much purpose in distinguishing between
the two, while the engine doesn't make the distinction for normal untyped
properties.
If we make the distinction for typed properties,
Hello everyone,
I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.
https://wiki.php.net/rfc/typed-properties
I would really appreciate constructive feedback on this RFC, with a
few areas especially:
1. How scared are we th
On Wed, Mar 16, 2016 at 1:39 PM, Johannes Schlüter
wrote:
> On Wed, 2016-03-16 at 12:36 -0400, Phil Sturgeon wrote:
>> Hello everyone,
>>
>> I have completed the draft for an RFC, to add Typed Properties. The
>> patch has been written by the one and only Joe Watkins.
>>
>> https://wiki.php.net/rfc
Hi Joe,
> Accessing the property before it was unset though, as it always did,
> attempts to read the default value (null).
>
> We haven't changed any of that ...
>
Yes, you're right, this is exactly how it currently behaves :
https://3v4l.org/YpfYe (apologies for not checking this first).
Stil
On 16/03/16 22:20, Larry Garfield wrote:
> If it works on Linux just fine, why is it called Windows? Is that
> really what the ICU spec says to call them, rather than something
> meaningful? (That would be sad making if so.)
Simples ...
http://stackoverflow.com/questions/17348807/how-to-translat
On 3/15/2016 11:02 PM, Yasuo Ohgaki wrote:
> Hi Scott,
>
> On Wed, Mar 16, 2016 at 2:40 AM, Scott Arciszewski
> wrote:
>> Question: If this extension is adopted, which syntax would you prefer?
>>
>> \Sodium\func()
>> Sodium::func()
>> sodium_func()
>
> I prefer both of
>
> Sod
On 3/18/2016 9:56 PM, Levi Morrison wrote:
>> At least that's not what it says in the docs.
>
> I meant: at least according to the docs:
> http://php.net/manual/en/language.namespaces.rationale.php
>
>> Namespace names PHP and php, and compound names starting with these names
>> (like PHP\Class
On 3/16/2016 10:12 PM, Björn Larsson wrote:
> Like the RFC :)
>
> Could this be an opportunity to have default visibility for property's when
> they are typed in a similar fashion like for functions? Meaning no
> visibility
> implies public and code below would work.
> class A {
> int $i=7;
>
On 3/16/16 11:36 AM, Phil Sturgeon wrote:
Hello everyone,
I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.
https://wiki.php.net/rfc/typed-properties
Overall thought: <3
I would really appreciate constructive feedback
Hi all,
first up, major thanks to both Joe and Phil for putting this together.
I'm fully behind the concept of typed properties and think it would be a
great feature to have in the language.
I have a few points I'd like to make on the current implementation being
proposed.
1) There's an issue
Hi!
> Pretty basic RFC: There's new methods in ICU 52, wrap 'em up and make
> 'em available.
> Note that despite these APIs being windows focused, they are in fact
> available on Linux.
> They're just a database lookup, essentially.
> https://wiki.php.net/rfc/intl.timezone.get-windows-id
Looks pr
Quick update folks, the RFC patch now respects strict mode, so will be
weak by default and strict if enabled.
I'll update the RFC to reflect this soon, but I'm busy today and it
won't get done until tomorrow.
Also there is definitely no void keyword for properties.
We'll move onto working out de
On Thu, Mar 17, 2016 at 12:00 AM, Larry Garfield
wrote:
> On 3/16/16 2:30 PM, Andrey Andreev wrote:
>
>> Also, a LOT of code would end up with e.g. a default value of 0 for an
>> integer property, still having to check if it was properly populated with a
>> positive value - not much of an improve
Hi Johannes,
Johannes Schlüter wrote:
On Wed, 2016-03-16 at 19:15 +0100, Bob Weinand wrote:
Eih, only to typed properties. Everything else would be insane ;-)
Sorry for being imprecise.
Ok, quite a lot better, but still weird difference to the language.
There's a notable amount of places w
Hi Dmitry,
Thanks for your reply! You're correct. let me try to explain your points:
If I have a main.php and worker.php
And I defined work($worker) { $status = $worker->getStatus(); } inside
main.php
when main.php is compiled, we don't know what the class entry of $worker
is. What we only kno
On Wed, Mar 16, 2016 at 12:49 PM, Will Fitch wrote:
>
>
> On Wed, Mar 16, 2016, at 11:36 AM, Phil Sturgeon wrote:
>> Hello everyone,
>>
>> I have completed the draft for an RFC, to add Typed Properties. The
>> patch has been written by the one and only Joe Watkins.
>>
>> https://wiki.php.net/rfc/t
Morning Lee,
Phil is in a field somewhere, but I don't want to leave you hanging on for
an answer ... so ...
class Foo
{
public $bar;
public function __get($name)
{
return 123;
}
}
$foo = new Foo();
var_dump($foo->bar);
You should not expect __get to be called in this ex
73 matches
Mail list logo
