On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov nikita@gmail.com 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,
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 of
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 -
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 to
On Tue, Feb 17, 2015 at 4:35 PM, Nikita Popov nikita@gmail.com 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
On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf ras...@lerdorf.com 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
On Tue, Feb 17, 2015 at 11:03 PM, Sara Golemon poll...@php.net 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
Will update RFC today, thanks for working on it Dmitry :)
Cheers
Joe
On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov dmi...@zend.com 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
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:
go forward. the patch looks fine.
Thanks. Dmitry.
On Tue, Feb 17, 2015 at 5:47 PM, Stanislav Malyshev smalys...@gmail.com
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.
--
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
On Wed, Feb 18, 2015 at 4:05 AM, Nikita Popov nikita@gmail.com wrote:
On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf ras...@lerdorf.com
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
-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 KEY
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:
OK thanks.
I'm switching to another task :)
Thanks. Dmitry.
On Wed, Feb 18, 2015 at 10:16 AM, Joe Watkins pthre...@pthreads.org 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
On Tue, Feb 17, 2015 at 8:35 PM, Tim Bezhashvyly tim.bezhashv...@gmail.com
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
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 dmi...@zend.com:
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
On Tue, Feb 17, 2015 at 3:30 AM, Leigh lei...@gmail.com wrote:
On 17 February 2015 at 05:48, Sara Golemon poll...@php.net 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
Hi,
On Tue, Feb 17, 2015 at 6:50 PM, Zeev Suraski z...@zend.com wrote:
On 17 בפבר׳ 2015, at 18:32, Andrey Andreev n...@devilix.net wrote:
Hi,
On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote:
If it gave both sides exactly what they wanted, how come it generated so
much
2015-02-17 16:35 GMT+03:00 Rowan Collins rowan.coll...@gmail.com:
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
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:
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* bool. (int
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
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
Hi Jakub,
On Sun, February 15, 2015 21:18, Jakub Zelenka wrote:
On Wed, Feb 11, 2015 at 11:56 AM, Jakub Zelenka bu...@php.net 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
On Tue, Feb 17, 2015 at 5:06 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Feb 16, 2015 at 10:15 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Nikita,
On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov nikita@gmail.com
wrote:
On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov
On Tue, Feb 17, 2015 at 4:50 PM, François Laupretre franc...@php.net
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 :
On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com 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
On 17 בפבר׳ 2015, at 18:32, Andrey Andreev n...@devilix.net wrote:
Hi,
On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com 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
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 hints, and
-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 compromise
On Tue, Feb 17, 2015 at 5:38 PM, Sara Golemon poll...@php.net wrote:
On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com
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
On 02/17/2015 08:38 AM, Sara Golemon wrote:
On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com 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
On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Nikita,
it looks like a part of old implementation is not trivial with new AST
compiler.
previously we translated assert(condition) into
Hi,
On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com 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
Alexander Lisachenko wrote on 17/02/2015 14:21:
2015-02-17 16:35 GMT+03:00 Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com:
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
On Mon, Feb 16, 2015 at 10:15 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Nikita,
On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov nikita@gmail.com
wrote:
On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov dmi...@zend.com wrote:
On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei
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
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
Alexander Lisachenko wrote on 17/02/2015 12:41:
2015-02-17 15:29 GMT+03:00 Benjamin Eberlei kont...@beberlei.de:
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
Hi,
On Tue, Feb 17, 2015 at 5:02 PM, Dennis Birkholz den...@birkholz.biz 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
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
sense
On Tue, Feb 17, 2015 at 1:30 PM, Leigh lei...@gmail.com wrote:
On 17 February 2015 at 05:48, Sara Golemon poll...@php.net 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
Hi,
On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski z...@zend.com 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
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. (int
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 conversion to any
-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 bool -
On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com 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
On Tue, Feb 17, 2015 at 7:02 AM, Dennis Birkholz den...@birkholz.biz 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
HI Dmitry,
Question : in which scope do you evaluate the PHP expression ?
Example :
DbC.requires($a 0);
DbC.ensures(__RETURN__ 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
-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 Suraski
Hello, Lars!
2015-02-17 22:09 GMT+03:00 Lars Strojny l...@strojny.net:
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
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 thinking
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 valid
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 can't
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 ?php_strict -- that feels most PHP to me.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
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.
Hopefully
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.
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
2015-02-17 19:25 GMT+03:00 Dmitry Stogov dmi...@zend.com:
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
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,
Le Tue, 17 Feb 2015 00:58:18 +0100, Sara Golemon poll...@php.net a écrit:
On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net
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
Hi Alexander,
On 17 Feb 2015, at 12:46, 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
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
On 17 February 2015 at 05:48, Sara Golemon poll...@php.net 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
On 17 February 2015 at 11:46, 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:
On 17 February 2015 at 17:35, Tim Bezhashvyly tim.bezhashv...@gmail.com 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
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
2015-02-17 20:35 GMT+03:00 Tim Bezhashvyly tim.bezhashv...@gmail.com:
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,
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 simply
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)
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 great.
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
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
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
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. And,
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 it up. I
Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com:
On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com 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
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
Am 17.02.2015 um 11:21 schrieb Benjamin Eberlei kont...@beberlei.de:
On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand bobw...@hotmail.com
mailto:bobw...@hotmail.com wrote:
Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com
mailto:nikita@gmail.com:
On Mon, Oct 6, 2014
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!
On Tue, Feb 17, 2015 at 9:22 AM, Rasmus Lerdorf ras...@lerdorf.com 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
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 $ch, int
2015-02-17 0:58 GMT+01:00 Sara Golemon poll...@php.net:
On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net
wrote:
Straw poll:
1) ?php strict;
2) ?php-strict
3) use strict; (psuedo-namespace)
4) ?php // strict (I don't actually like HHVM's style, but if you do...)
5)
On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand bobw...@hotmail.com wrote:
Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com:
On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com
wrote:
Hi internals!
During the PHP 5.6 development cycle I have proposed an
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
2015-02-17 15:06 GMT+03:00 Leigh lei...@gmail.com:
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
2015-02-17 15:09 GMT+03:00 Benjamin Eberlei kont...@beberlei.de:
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:29 GMT+03:00 Benjamin Eberlei kont...@beberlei.de:
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
On 17 February 2015 at 12:22, Alexander Lisachenko
lisachenko...@gmail.com 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
On Mon, 16 Feb 2015, Sara Golemon wrote:
On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net 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
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:
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 kont...@beberlei.de:
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
2015-02-17 15:48 GMT+03:00 Leigh lei...@gmail.com:
So: Internal Parse AST - Extension Parse AST - Generate OpCodes -
OpCache?
Yes, it's correct flow.
2015-02-17 15:48 GMT+03:00 Leigh lei...@gmail.com:
So if the parser extension does anything dynamic, then OpCache will
have the wrong
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
95 matches
Mail list logo
