Re: [PHP-DEV] RFC: Expectations

OK thanks. I'm switching to another task :) Thanks. Dmitry. On Wed, Feb 18, 2015 at 10:16 AM, Joe Watkins wrote: > Updated RFC as requested. > > I'm just going to wait to hear what Nikita says, especially about > optimizing away unqualified calls to assert. > I guess this could be viewed as

Re: [PHP-DEV] RFC: Expectations

Updated RFC as requested. I'm just going to wait to hear what Nikita says, especially about optimizing away unqualified calls to assert. I guess this could be viewed as a BC break, it seems like quite a nice break but not sure. Will open voting when we hear from Nikita. Cheers Joe On Wed, Feb 1

Re: [PHP-DEV] [RFC] Spaceship operator RFC

go forward. the patch looks fine. Thanks. Dmitry. On Tue, Feb 17, 2015 at 5:47 PM, Stanislav Malyshev wrote: > Hi! > > As expected, spaceship operator RFC > (https://wiki.php.net/rfc/combined-comparison-operator) passed 43 votes > to 11. I'll proceed with merging it soon. > -- > Stas Malyshev >

Re: [PHP-DEV] Annotations in PHP7

On Wed, Feb 18, 2015 at 12:51 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > François, > > Doctrine relies on nested annotations for a variety of mapping information. > One example: > > > http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-m

RE: [PHP-DEV] Scalar Type Hints v0.4

> -Original Message- > From: Nikita Popov [mailto:nikita@gmail.com] > Sent: Wednesday, February 18, 2015 3:06 AM > To: Rasmus Lerdorf > Cc: Sara Golemon; PHP internals > Subject: Re: [PHP-DEV] Scalar Type Hints v0.4 > > The inability to implicitly cast "123" to int is pretty much the KE

Re: [PHP-DEV] Annotations in PHP7

On Tue, Feb 17, 2015 at 10:13 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > > 2015-02-17 19:25 GMT+03:00 Dmitry Stogov : > >> I think yes, >> However, Alexander thinks differently >> https://wiki.php.net/rfc/parser-extension-api >> Of course this is not for 7.0 >> > > This RFC consi

Re: [PHP-DEV] RFC: Expectations

Will update RFC today, thanks for working on it Dmitry :) Cheers Joe On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov wrote: > Hi Joe > > The patch is ready https://github.com/php/php-src/pull/1088/files > > 1) I implemented AST pretty-printer to reconstruct the source. It may be > reused in Refl

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

Hi, On Tue, Feb 17, 2015 at 2:46 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > Hello, internals! > > I want to introduce a RFC for providing a userland API for accessing an > Abstract Syntax Tree of the source code and to provide userland parser > hooks for source code modification

Re: [PHP-DEV] RFC Proposal

On Tue, Feb 17, 2015 at 8:35 PM, Tim Bezhashvyly wrote: > Dear PHP internals, > > this is my first RFC proposal and I am not sure if in this email is > supposed to contain all RFC details or just a brief idea .. which is to > drop PHP constants in favour of “final" immutable variables. > I think

Re: [PHP-DEV] Scalar Type Hints v0.4

On Wed, Feb 18, 2015 at 4:05 AM, Nikita Popov wrote: > On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf > wrote: > > > On 02/17/2015 04:35 PM, Nikita Popov wrote: > > > I don't buy into Rasmus arguments about internal functions. They > concern > > > one particular edge case (int->float coercion)

Re: [PHP-DEV] zend_get_parameters_ex rework

On 17/02/15 23:40, Jan Ehrhardt wrote: >> Thanks patch looks clean and It compiles, i will start testing it > Apparently your tests were successful (?): > http://git.php.net/?p=php-src.git;a=commitdiff;h=8f968c5416e721983c0efda25ec1f393c8df662a Adrian may have, but I've just wasted 2 hours trying

Re: [PHP-DEV] Scalar Type Hints v0.4

On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov wrote: > This is exactly what I fear will happen with an arginfo based approach. If > even fundamental aspects like the "123" vs 123 (or true vs 1) distinction > are suppressed for internal functions, this isn't a strict typing mode, it's > just a weak

Re: [PHP-DEV] Scalar Type Hints v0.4

On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf wrote: > On 02/17/2015 04:35 PM, Nikita Popov wrote: > > I don't buy into Rasmus arguments about internal functions. They concern > > one particular edge case (int->float coercion) and I doubt they have much > > relevance if applied to codebases wit

Re: [PHP-DEV] Scalar Type Hints v0.4

On Tue, Feb 17, 2015 at 4:35 PM, Nikita Popov wrote: > I don't like the way this is heading with regards to internal functions. > Apart from better inter-compatibility, the primary appeal of Andrea's > proposal was that we have the option to make not only userland function > calls strict, but inte

Re: [PHP-DEV] Scalar Type Hints v0.4

On 02/17/2015 04:35 PM, Nikita Popov wrote: > I don't buy into Rasmus arguments about internal functions. They concern > one particular edge case (int->float coercion) and I doubt they have much > relevance if applied to codebases with pervasive use of typehints (where > you can be reasonably sure

Re: [PHP-DEV] Scalar Type Hints v0.4

On Tue, Feb 17, 2015 at 11:03 PM, Sara Golemon wrote: > Based on conversations here and elsewhere on the internet, I'd like to > put forward a rough gameplan for scalar types which I hope addresses > most concerns. This is back-of-the-napkin and I'm not asking for a > committed yes/no, just pre-

Re: [PHP-DEV] zend_get_parameters_ex rework

marius adrian popa in php.internals (Fri, 13 Feb 2015 17:56:28 +0200): >Thanks patch looks clean and It compiles, i will start testing it Apparently your tests were successful (?): http://git.php.net/?p=php-src.git;a=commitdiff;h=8f968c5416e721983c0efda25ec1f393c8df662a Jan -- PHP Internals - P

Re: [PHP-DEV] Reviving scalar type hints

On 17/02/15 21:28, François Laupretre wrote: >> De : Lester Caine [mailto:les...@lsces.co.uk] >> >> On 17/02/15 18:33, François Laupretre wrote: >>> What does this mean in your case ? Just that, as long as the feature is not >> available, your function won't have an explicit return type. Period. An

[PHP-DEV] Scalar Type Hints v0.4

Based on conversations here and elsewhere on the internet, I'd like to put forward a rough gameplan for scalar types which I hope addresses most concerns. This is back-of-the-napkin and I'm not asking for a committed yes/no, just pre-rfc set of thoughts. Please don't get hung up on specific names

Re: [PHP-DEV] Annotations in PHP7

François, Doctrine relies on nested annotations for a variety of mapping information. One example: http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table []s, On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre wrote: > Hi A

Re: [PHP-DEV] RFC: Expectations

Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.a

RE: [PHP-DEV] Annotations in PHP7

Hi Alexander, > De : Alexander Lisachenko [mailto:lisachenko...@gmail.com] > > This RFC consists of two parts: parsing API and parser extension API. Last > one can be rejected, however it can be perfectly connected with annotation > RFC (if AST will be used as values) Parser extension API is grea

RE: [PHP-DEV] Reviving scalar type hints

> De : Lester Caine [mailto:les...@lsces.co.uk] > > On 17/02/15 18:33, François Laupretre wrote: > > What does this mean in your case ? Just that, as long as the feature is not > available, your function won't have an explicit return type. Period. And, > please, don't change false to 0 ;). > > I s

Re: [PHP-DEV] Reviving scalar type hints

On 17/02/15 18:33, François Laupretre wrote: > What does this mean in your case ? Just that, as long as the feature is not > available, your function won't have an explicit return type. Period. And, > please, don't change false to 0 ;). I simply can't see the case for limited function type hints

Re: [PHP-DEV] RFC Proposal

2015-02-17 20:35 GMT+03:00 Tim Bezhashvyly : > this is my first RFC proposal and I am not sure if in this email is > supposed to contain all RFC details or just a brief idea .. which is to > drop PHP constants in favour of “final" immutable variables. Hello, Tim Recently, I asked this question

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

Hello, Lars! 2015-02-17 22:09 GMT+03:00 Lars Strojny : > Looks cool and I could see a couple of interesting possibilities arising. > One thing: any particular reason ExtensionInterface is static? I could see > a couple of benefits having extensions carry state and registerExtension() > taking an

Re: [PHP-DEV] RFC Proposal

On 17 February 2015 at 17:35, Tim Bezhashvyly wrote: > Dear PHP internals, > > this is my first RFC proposal and I am not sure if in this email is supposed > to contain all RFC details or just a brief idea .. which is to drop PHP > constants in favour of “final" immutable variables. I think we

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

Hi Alexander, > On 17 Feb 2015, at 12:46, Alexander Lisachenko > wrote: > > Hello, internals! > > I want to introduce a RFC for providing a userland API for accessing an > Abstract Syntax Tree of the source code and to provide userland parser > hooks for source code modification: > https://wi

RE: [PHP-DEV] Reviving scalar type hints

> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara > Golemon > > > 1. Tighten up the type coercion for the "1000 dogs" case although we > >have to look at whether there is a problem with some database APIs > >returning space-padded fields so "1000" would now break. > >

Re: [PHP-DEV] Annotations in PHP7

2015-02-17 19:25 GMT+03:00 Dmitry Stogov : > I think yes, > However, Alexander thinks differently > https://wiki.php.net/rfc/parser-extension-api > Of course this is not for 7.0 > This RFC consists of two parts: parsing API and parser extension API. Last one can be rejected, however it can be per

RE: [PHP-DEV] Reviving scalar type hints

> De : François Laupretre [mailto:franc...@php.net] > > This way, the user can write : > > function convertToInt(string $number): int! { <- int! instead of int > if (!preg_match("(^[0-9]{1,17}$)", $number)) { > throw new InvalidArgumentException("Supplied argument is not a va

RE: [PHP-DEV] Reviving scalar type hints

Hi, Starting making the strict mode weaker is nonsense. It is not just Rasmus' example. Which exception do you authorize then ? Would you define a third 'pseudo-strict' mode ? And about static analyzers, will they be 'pseudo-strict' too ? No, if you want strict, it can only remain purely stric

Re: [PHP-DEV] Reviving scalar type hints

> I like 2) No possible confusion, and it's a clear tag. I agree, but it feels like it gets away from PHP's underscore-heavy syntax. The poll omitted http://www.php.net/unsub.php

RE: [PHP-DEV] Reviving scalar type hints

> De : Lester Caine [mailto:les...@lsces.co.uk] > > My current practice up until now has been to use 'return false' when an > action failed, but the main return would be a number of records or > string of data. So you are now blocking that activity ... I'm reading to > right, but you are not thinki

RE: [PHP-DEV] Reviving scalar type hints

> Yes, I already know that. > The difference, and why I keep pointing that out, is that me and many > others > want strict typing for our own reasons (but still in its entirety instead > of as a > limited mode) and most of us don't even care if you getting weak typing > for > your own usage. You ca

Re: [PHP-DEV] Reviving scalar type hints

Le Tue, 17 Feb 2015 00:58:18 +0100, Sara Golemon a écrit: On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre wrote: Once again, anyone can take over version 0.3, if it is so great. Why don't you do it ? I will play the game, stop working on my proposal, and vote 'yes' again. But don't ask

RE: [PHP-DEV] RFC Proposal

Hi Tim, I imagine you're proposing to drop class constants only, not PHP constants ? If you want to drop PHP constants, stop wasting your time on this :) While that's the place to discuss it before you start an RFC, the concept is a little short. Could you give at least syntax examples and, mo

RE: [PHP-DEV] Reviving scalar type hints

Hi Anthony, I understand your concerns and think the work we are doing should be suitable to compilers and static analyzers, but that's hard to make everyone happy. One thing I thought we should reserve for a future release is the addition of a set of strict type hints : something like (just ex

[PHP-DEV] RFC Proposal

Dear PHP internals, this is my first RFC proposal and I am not sure if in this email is supposed to contain all RFC details or just a brief idea .. which is to drop PHP constants in favour of “final" immutable variables. This is basically only a concept but I can also handle its implementation.

Re: [PHP-DEV] Reviving scalar type hints

Hi, On Tue, Feb 17, 2015 at 6:50 PM, Zeev Suraski wrote: > >> On 17 בפבר׳ 2015, at 18:32, Andrey Andreev wrote: >> >> Hi, >> >>> On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski wrote: >>> >>> If it gave both sides exactly what they wanted, how come it generated so >>> much objection? >>> >>> Simp

Re: [PHP-DEV] Reviving scalar type hints

On 02/17/2015 08:38 AM, Sara Golemon wrote: > On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf wrote: >> Please correct me here if I somehow ran these incorrectly. I did put >> some deliberate type errors into my userspace code and hh_client caught >> those nicely, so it seems like it was working,

Re: [PHP-DEV] Reviving scalar type hints

On Tue, Feb 17, 2015 at 5:38 PM, Sara Golemon wrote: > On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf > wrote: > > On 02/16/2015 09:48 PM, Sara Golemon wrote: > >> Second, I should clarify that while the HHVM runtime performs > >> coersion, the hack type checker is strict. So my original stat

Re: [PHP-DEV] new json, push generated file?

Hi Jakub, On Sun, February 15, 2015 21:18, Jakub Zelenka wrote: > On Wed, Feb 11, 2015 at 11:56 AM, Jakub Zelenka wrote: > >> >> >> I would like to push the the bison tab files shortly as the majority of >> people in this thread (including me) are for having them in the repo. >> The >> only thin

Re: [PHP-DEV] Reviving scalar type hints

> On 17 בפבר׳ 2015, at 18:32, Andrey Andreev wrote: > > Hi, > >> On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski wrote: >> >> If it gave both sides exactly what they wanted, how come it generated so >> much objection? >> >> Simply put, because it absolutely doesn't give both sides what they wa

Re: [PHP-DEV] Reviving scalar type hints

On Tue, Feb 17, 2015 at 3:30 AM, Leigh wrote: > On 17 February 2015 at 05:48, Sara Golemon wrote: We can sigh and tut about this not being "the PHP way", but the script author was the one who chose to enter into a tight contract, and the script author, not you, is the one who shoul

RE: [PHP-DEV] Reviving scalar type hints

> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Tuesday, February 17, 2015 5:48 PM > To: Zeev Suraski > Cc: franc...@php.net; Sara Golemon; PHP internals > Subject: Re: [PHP-DEV] Reviving scalar type hints > > Zeev et al, > > Because it > **wasn't** a compr

Re: [PHP-DEV] Reviving scalar type hints

On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf wrote: > On 02/16/2015 09:48 PM, Sara Golemon wrote: >> Second, I should clarify that while the HHVM runtime performs >> coersion, the hack type checker is strict. So my original statement >> was inaccurate. As far as hack is concerned, it's simpl

Re: [PHP-DEV] Reviving scalar type hints

Hi, On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski wrote: >> -Original Message- >> From: Anthony Ferrara [mailto:ircmax...@gmail.com] >> Sent: Tuesday, February 17, 2015 5:48 PM >> To: Zeev Suraski >> Cc: franc...@php.net; Sara Golemon; PHP internals >> Subject: Re: [PHP-DEV] Reviving scal

Re: [PHP-DEV] Reviving scalar type hints

On 17/02/2015 15:47, Anthony Ferrara wrote: If we want to add a "numeric" type as a virtual union of int and float, that's one way to solve the concern. If we don't, we could also allow widening primitive conversion (int -> float). That wouldn't work well with bigints, but would be fine in other

Re: [PHP-DEV] Re: Annotations in PHP7

On Tue, Feb 17, 2015 at 4:50 PM, François Laupretre wrote: > HI Dmitry, > > Question : in which scope do you evaluate the PHP expression ? > We don't evaluate expressions. We just store them. Evaluation and/or modification is a subject for future development. > > Example : > > 0);> > 0);> >

Re: [PHP-DEV] Reviving scalar type hints

On 17/02/15 15:47, Anthony Ferrara wrote: > A static analyzer (one of the reasons people want strict) would error > there. The reason is that *at compile time* it can't reason about the > code well enough to determine if there's an error or not. You're > passing a string where you expect an int. Is

Re: [PHP-DEV] Annotations in PHP7

On Tue, Feb 17, 2015 at 5:06 PM, Nikita Popov wrote: > On Mon, Feb 16, 2015 at 10:15 PM, Dmitry Stogov wrote: > >> Hi Nikita, >> >> On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov >> wrote: >> >>> On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov wrote: >>> On Mon, Feb 16, 2015 at

Re: [PHP-DEV] Reviving scalar type hints

On 17/02/15 15:30, François Laupretre wrote: >> Returning 'not-zero/empty' as true and 'zero' as false is one of the >> > natural things to use in PHP and I don't think any other language has >> > that flexibility? > You didn't read it right. > > I was talking of conversions *from* bool, not *to*

Re: [PHP-DEV] RFC: Expectations

On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov wrote: > On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov wrote: > >> Hi Nikita, >> >> it looks like a part of old implementation is not trivial with new AST >> compiler. >> >> previously we translated assert(condition) into assert(condition, >> "asser

RE: [PHP-DEV] Reviving scalar type hints

> De : Andrey Andreev [mailto:n...@devilix.net] > > > If we still see that employing the strict(er) rules is very noisy with > > internal functions, a more appropriate option may be introducing new > types > > into ZPP, that would correspond to the new rules we introduce in the > > userland type hi

Re: [PHP-DEV] Reviving scalar type hints

Zeev et al, >> 2. It is not not about being lossless or not. People expect bool -> int to >> be >> disabled, for example, and it is not lossless. >> >> 3. It is more a question of finding a consensus about conversions which >> don't >> make sense, and disabling them. Examples include bool conversi

RE: [PHP-DEV] Reviving scalar type hints

> De : Lester Caine [mailto:les...@lsces.co.uk] > > Returning 'not-zero/empty' as true and 'zero' as false is one of the > natural things to use in PHP and I don't think any other language has > that flexibility? You didn't read it right. I was talking of conversions *from* bool, not *to* bool. (

Re: [PHP-DEV] Reviving scalar type hints

On 17/02/15 14:49, Andrey Andreev wrote: >> I agree. It's more of a question of eliminating potentially dangerous >> > conversions than just being lossless. >> > > Agreed as well. However, while bool -> int conversion one of the > reasons why many people want strict type-hints, it also often makes

Re: [PHP-DEV] Reviving scalar type hints

On Tue, Feb 17, 2015 at 7:02 AM, Dennis Birkholz wrote: > Am 17.02.2015 um 12:30 schrieb Leigh: >> And you find taking authority over a library away from the library >> author completely acceptable? >> >> If I write an API that works perfectly well in strict mode, why >> shouldn't I be able to tur

RE: [PHP-DEV] Reviving scalar type hints

> -Original Message- > From: Andrey Andreev [mailto:n...@devilix.net] > Sent: Tuesday, February 17, 2015 4:49 PM > To: Zeev Suraski > Cc: franc...@php.net; Sara Golemon; PHP internals > Subject: Re: [PHP-DEV] Reviving scalar type hints > > Hi, > > On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suras

Re: [PHP-DEV] Reviving scalar type hints

Hi, On Tue, Feb 17, 2015 at 5:02 PM, Dennis Birkholz wrote: > Am 17.02.2015 um 12:30 schrieb Leigh: >> And you find taking authority over a library away from the library >> author completely acceptable? >> >> If I write an API that works perfectly well in strict mode, why >> shouldn't I be able t

[PHP-DEV] [RFC] Spaceship operator RFC

Hi! As expected, spaceship operator RFC (https://wiki.php.net/rfc/combined-comparison-operator) passed 43 votes to 11. I'll proceed with merging it soon. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.

RE: [PHP-DEV] Reviving scalar type hints

> De : Zeev Suraski [mailto:z...@zend.com] > > Even though that's not what I meant when I sent my proposal in the > morning, Sorry, I was not clear enough : it was my position only. > I've been wondering about the same thing (also with the feedback from > Dmitry). Can go an extra step from both

Re: [PHP-DEV] Reviving scalar type hints

Am 17.02.2015 um 12:30 schrieb Leigh: > And you find taking authority over a library away from the library > author completely acceptable? > > If I write an API that works perfectly well in strict mode, why > shouldn't I be able to turn strict on for my whole library? Do I just > tell users that n

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

Alexander Lisachenko wrote on 17/02/2015 14:21: 2015-02-17 16:35 GMT+03:00 Rowan Collins >: The other alternative is to go to the other extreme, and have the extensions scoped to a particular file, more like Perl pragmas. Dare I say we could use the de

Re: [PHP-DEV] Reviving scalar type hints

On Tue, Feb 17, 2015 at 1:30 PM, Leigh wrote: > On 17 February 2015 at 05:48, Sara Golemon wrote: We can sigh and tut about this not being "the PHP way", but the script author was the one who chose to enter into a tight contract, and the script author, not you, is the one who shoul

Re: [PHP-DEV] Reviving scalar type hints

Hi, On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski wrote: >> -Original Message- >> From: François Laupretre [mailto:franc...@php.net] >> Sent: Tuesday, February 17, 2015 2:58 PM >> To: 'Sara Golemon'; 'Zeev Suraski' >> Cc: 'PHP internals' >> Subject: RE: [PHP-DEV] Reviving scalar type hint

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-17 16:35 GMT+03:00 Rowan Collins : > I think "should" is OK for extensions, but not for userland hooks. There > needs to be a very firm definition of the right and wrong way to implement > these hooks, which can at the very least warn the user when they are > slipping into undefined behavi

Re: [PHP-DEV] RFC: Expectations

On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov wrote: > Hi Nikita, > > it looks like a part of old implementation is not trivial with new AST > compiler. > > previously we translated assert(condition) into assert(condition, > "assert(condition)"). > actually we just captured a part of input buffe

Re: [PHP-DEV] Annotations in PHP7

On Mon, Feb 16, 2015 at 10:15 PM, Dmitry Stogov wrote: > Hi Nikita, > > On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov > wrote: > >> On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov wrote: >> >>> >>> >>> On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei >>> wrote: >>> On Mon, Fe

RE: [PHP-DEV] Re: Annotations in PHP7

HI Dmitry, Question : in which scope do you evaluate the PHP expression ? Example : 0);> 0);> function foo($a) { ... How can you know from this that the first expression must be evaluated at function entry, that the second one must be interpreted when function exits, let alone the question

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

Alexander Lisachenko wrote on 17/02/2015 12:41: 2015-02-17 15:29 GMT+03:00 Benjamin Eberlei : Well not really, depending on the path towards a require a parser extension is already registered or not. Or you have conditional registration of extensions. So you could load a file with an extension

RE: [PHP-DEV] Reviving scalar type hints

> -Original Message- > From: François Laupretre [mailto:franc...@php.net] > Sent: Tuesday, February 17, 2015 2:58 PM > To: 'Sara Golemon'; 'Zeev Suraski' > Cc: 'PHP internals' > Subject: RE: [PHP-DEV] Reviving scalar type hints > > 2. It is not not about being lossless or not. People expect

Re: [PHP-DEV] Reviving scalar type hints

On Mon, 16 Feb 2015, Sara Golemon wrote: > On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre wrote: > > Once again, anyone can take over version 0.3, if it is so great. Why don't > > you do it ? > > I will play the game, stop working on my proposal, and vote 'yes' again. > > But don't ask me t

RE: [PHP-DEV] Reviving scalar type hints

Hi Sara, > De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara > Golemon > > So, if you'll permit me to summarize your message. The following > would be palatable to you? > > * Lossless coercion. This would sit somewhere between strict types > and weak types as lossy conversions

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-17 15:48 GMT+03:00 Leigh : > So: Internal Parse AST -> Extension Parse AST -> Generate OpCodes -> > OpCache? > Yes, it's correct flow. 2015-02-17 15:48 GMT+03:00 Leigh : > So if the parser extension does anything dynamic, then OpCache will > have the wrong version cached. > This restri

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

On 17 February 2015 at 12:22, Alexander Lisachenko wrote: > Yes, parser extensions will be called for all require/include/evals after > registration. This part is transparent for opcache, because opcache just > stores an opcodes for the file. AST is parsed only once for each file, then > hooks can

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-17 15:29 GMT+03:00 Benjamin Eberlei : > Well not really, depending on the path towards a require a parser > extension is already registered or not. Or you have conditional > registration of extensions. So you could load a file with an extension > registered, but it still serves the old opc

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

On Tue, Feb 17, 2015 at 1:22 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > > 2015-02-17 15:09 GMT+03:00 Benjamin Eberlei : > >> The visitor API is the essential part here and you left it out. > > > Yes, I decided not to put Visitor in the RFC (this was added as open > question to th

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-17 15:09 GMT+03:00 Benjamin Eberlei : > The visitor API is the essential part here and you left it out. Yes, I decided not to put Visitor in the RFC (this was added as open question to the RFC). But this part can be discussed in the case of general acceptance. 2015-02-17 15:09 GMT+03:0

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2015-02-17 15:06 GMT+03:00 Leigh : > Does the AST provided by the internal parser provide all of the > information required to be able to turn it back into source code? > > Yes, this should be possible, via zend_emit_op*() and zend_compile*() 2015-02-17 15:06 GMT+03:00 Leigh : > Re: Extending t

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

On Tue, Feb 17, 2015 at 12:46 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > Hello, internals! > > I want to introduce a RFC for providing a userland API for accessing an > Abstract Syntax Tree of the source code and to provide userland parser > hooks for source code modification: >

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

On 17 February 2015 at 11:46, Alexander Lisachenko wrote: > Hello, internals! > > I want to introduce a RFC for providing a userland API for accessing an > Abstract Syntax Tree of the source code and to provide userland parser > hooks for source code modification: > https://wiki.php.net/rfc/parser

Re: [PHP-DEV] [RFC] Exceptions in the engine

Tony Marston wrote on 17/02/2015 09:59: "Rowan Collins" wrote in message news:54e1c993.1070...@gmail.com... Tony Marston wrote on 16/02/2015 10:09: This RFC only mentions errors with object methods, so what impact would it have with procedural functions. For example, if fopen('nonexistantfil

[PHP-DEV] [RFC][Discussion] Parser extension API

Hello, internals! I want to introduce a RFC for providing a userland API for accessing an Abstract Syntax Tree of the source code and to provide userland parser hooks for source code modification: https://wiki.php.net/rfc/parser-extension-api Thanks!

Re: [PHP-DEV] Reviving scalar type hints

On 17 February 2015 at 05:48, Sara Golemon wrote: >>> We can sigh and tut about this not being "the PHP way", but the script >>> author was the one who chose to enter into a tight contract, and the >>> script author, not you, is the one who should have that authority over >>> their own application

Re: [PHP-DEV] Reviving scalar type hints

On 17/02/15 06:20, Sara Golemon wrote: > * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as > standard (like numeric), others user-definable) And also ... int4, int8 and similar for correctly constrained values. In an ideal world the whole SQL standard types would be available, but t

Re: [PHP-DEV] [RFC] Exceptions in the engine

> Am 17.02.2015 um 11:21 schrieb Benjamin Eberlei : > On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand > wrote: > > Am 14.02.2015 um 00:25 schrieb Nikita Popov > >: > > > > On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov >

Re: [PHP-DEV] [RFC] Exceptions in the engine

On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand wrote: > > Am 14.02.2015 um 00:25 schrieb Nikita Popov : > > > > On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov > wrote: > > > >> Hi internals! > >> > >> During the PHP 5.6 development cycle I have proposed an RFC [1] that > >> suggested the use of ex

Re: [PHP-DEV] [RFC] Exceptions in the engine

> Am 14.02.2015 um 00:25 schrieb Nikita Popov : > > On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov wrote: > >> Hi internals! >> >> During the PHP 5.6 development cycle I have proposed an RFC [1] that >> suggested the use of exceptions instead of fatal errors in the engine. At >> the time the pro

Re: [PHP-DEV] [RFC] Exceptions in the engine

"Rowan Collins" wrote in message news:54e1c993.1070...@gmail.com... Tony Marston wrote on 16/02/2015 10:09: This RFC only mentions errors with object methods, so what impact would it have with procedural functions. For example, if fopen('nonexistantfile.txt') fails the return value is FALSE a

[PHP-DEV] Compile problems - Was Switch jumptable optimization

On 16/02/15 23:55, Rasmus Lerdorf wrote: >> this doesn't really look related to my patch. Did you do something wrong >> > when cloning my branch? Or forget a make clean or similar? >> > >> > Locally it works for me and echoes 1 as expected. > Ah, looks like you are right. A full distclean cleared

Re: [PHP-DEV] Reviving scalar type hints

2015-02-17 0:58 GMT+01:00 Sara Golemon : > On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre > wrote: > > Straw poll: > 1) 2) 3) use strict; (psuedo-namespace) > 4) 5) declare(strict=true); (As a top-level declare only) > 6) declare(strict=true); (exactly as in v0.3 -- maybe you liked it) >

Re: [PHP-DEV] Reviving scalar type hints

On 02/17/2015 01:11 AM, Benjamin Eberlei wrote: > I think curl_setopt is a misleading example in the typehinting > discussion, because > this kind of API does not benefit from it. The third argument depends > on the second argument and requires a "generic" type in code: > > curl_setopt(resource $c

Re: [PHP-DEV] Reviving scalar type hints

On Tue, Feb 17, 2015 at 9:22 AM, Rasmus Lerdorf wrote: > On 02/16/2015 09:48 PM, Sara Golemon wrote: > > Second, I should clarify that while the HHVM runtime performs > > coersion, the hack type checker is strict. So my original statement > > was inaccurate. As far as hack is concerned, it's si

Re: [PHP-DEV] Reviving scalar type hints

On 02/16/2015 09:48 PM, Sara Golemon wrote: > Second, I should clarify that while the HHVM runtime performs > coersion, the hack type checker is strict. So my original statement > was inaccurate. As far as hack is concerned, it's simply strict. > Period. With both the default (partial) type chec