Am 19.02.2015 um 08:14 schrieb Dmitry Stogov:
On Thu, Feb 19, 2015 at 2:12 AM, François Laupretre franc...@php.net
mailto:franc...@php.net wrote:
If I understand Dmitry correctly, this would be stored as the
compiler internal representation of the 'new Entity(foo)' code,
but this
Hello!
The PHP development team announces the immediate availability of PHP 5.5.22.
This release fixes several bugs and addresses CVE-2015-0235 and
CVE-2015-0273.
All PHP 5.5 users are encouraged to upgrade to this version.
For source downloads of PHP 5.5.22 please visit our
downloads page:
Hi Anthony,
I have been interested in this proposal for a while now. I'm not on internals,
but I have a question about your proposal.
1. declare(strict_types=1) (if used) is required to be the first
instruction in the file only. No other usages allowed.
How would this work with namespaces?
Hi,
On Fri, Feb 20, 2015 at 6:01 AM, François Laupretre franc...@php.net wrote:
Hi Levi,
Just my opinion :
Add 'resource', 'object', 'scalar', 'mixed', 'numeric'
Remove 'double' (avoid this alias if we decide to encourage 'float'
everywhere)
Not sure we'll use Boolean and integer but
On 20 February 2015 at 08:47, Markus Fischer mar...@fischer.name wrote:
This sounds two-folded to me: very cool (albeit I can't see a use-case
right now) on one hand and utter magic on the other.
Inclined to agree.
@Joe what use-case prompted this feature?
--
PHP Internals - PHP Runtime
I work on a massive codebase, 3m loc, the ability to document that we throw
SomeAssertionException in *insert circumstance* is extremely appealing. It
would allow us to structure the documentation and the code in a way that
really makes sense especially for new developers. The alternatives are not
On 20/02/15 05:49, Zeev Suraski wrote:
Pardon me for saying so, but I don't think you're on to a huge scoop here.
Scalar type hints - of all the kinds we've been talking about here, be them
strict, weak or coercive - can be easily emulated with a couple of lines of
code, we all know that.
Also, we don't optimize those away, it would not be sensible, because it's
not sensible to deploy those catch blocks in the first place.
Cheers
Joe
On Fri, Feb 20, 2015 at 8:38 AM, Joe Watkins pthre...@pthreads.org wrote:
The custom exception must derive from AssertionException, so the same
On 19.02.15 16:23, Dmitry Stogov wrote:
- how does zend.assertions and assert.exceptions work with
assert_options() , i.e. isn't the exception behavior meant to be an
addition to assert_options() too ?
zend.assertions control assert() compilation and execution
zend.assertions=-1
The custom exception must derive from AssertionException, so the same
optimization is possible.
Cheers
Joe
On Fri, Feb 20, 2015 at 8:28 AM, Xinchen Hui larue...@php.net wrote:
Hey:
On Thu, Feb 19, 2015 at 5:09 PM, Joe Watkins pthre...@pthreads.org
wrote:
Morning internals,
The
Hi!
Please, consider this a warning that I'll put this to vote again shortly.
https://wiki.php.net/rfc/pecl_http
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Adam,
Am 19.02.2015 um 22:40 schrieb Adam Harvey:
RFC: https://wiki.php.net/rfc/comparable
PR: https://github.com/php/php-src/pull/1097
I see a little problem here by allowing any comparison. Comparing is
used for ordering, but you can easily construct ordering mechanisms that
simply don't
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston tonymars...@hotmail.com
wrote:
I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
Hey:
On Thu, Feb 19, 2015 at 5:09 PM, Joe Watkins pthre...@pthreads.org wrote:
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
sorry, the thread is too long to read.. I am not sure whether there
was some similar opinion
Am 20.02.2015 09:47 schrieb Joe Watkins pthre...@pthreads.org:
Also, we don't optimize those away, it would not be sensible, because it's
not sensible to deploy those catch blocks in the first place.
So, do they become FATAL with production settings? Ideally a parse error
(ideally, because
Dmitry Stogov wrote in message
news:CA+9eiLu634OpuXVT8NnwZwitqc=s4g8ubbmj+cob4nmqcpx...@mail.gmail.com...
On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston tonymars...@hotmail.com
wrote:
Rowan Collins wrote in message news:54e4fac2.7060...@gmail.com...
Tony Marston wrote on 18/02/2015
Hi Dmitry,
On Fri, Feb 20, 2015 at 4:15 PM, Dmitry Stogov dmi...@zend.com wrote:
I'm not sure. Currently we don't use namespaces for core classes, but I
won't object to change this.
Nikita, what do you think?
Thanks. Dmitry.
On Fri, Feb 20, 2015 at 10:01 AM, Yasuo Ohgaki
On 19.02.15 22:40, Adam Harvey wrote:
Those of you with long memories will remember that I proposed a
Comparable interface way back in the pre-5.4 days, but withdrew it
when it became obvious that there was no consensus for it as a feature
and that a vote was likely to fail.
RFC:
Hi internals,
In Operator is now in discussion phase.
This RFC adds a new in operator which simplifies contains checks for strings
and arrays.
Currently, we have to usein_array($needle, $haystack, true) or
strpos($haystack, $needle) !== false.
These functions have a inconsistent parameter
The alternatives are not nice, in my opinion.
What are this alternatives? What are the drawbacks of warning in
production code?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Feb 19, 2015 at 10:40 PM, Adam Harvey ahar...@php.net wrote:
Hi all,
Those of you with long memories will remember that I proposed a
Comparable interface way back in the pre-5.4 days, but withdrew it
when it became obvious that there was no consensus for it as a feature
and that a
can you please explain a bit more how you would achieve this in 3m loc?
AssertionExceptions are not intended to be caught, they are intended to be
seen, in a specific environment.
It doesn't really make sense to commit/deploy code that catches
AssertionExceptions knowing that the code is
On Fri, Feb 20, 2015 at 8:29 AM, Marcio Almada marcio.w...@gmail.com
wrote:
Hi internals,
I'd like to put the Context Sensitive Lexer RFC into discussion phase:
RFC: https://wiki.php.net/rfc/context_sensitive_lexer
TL;DR commit: https://github.com/marcioAlmada/php-src/commit/c01014f9
PR:
Am 20.02.2015 um 12:27 schrieb Joe Watkins:
I work on a massive codebase, 3m loc, the ability to document that we throw
SomeAssertionException in *insert circumstance* is extremely appealing. It
would allow us to structure the documentation and the code in a way that
really makes sense
On Fri, Feb 20, 2015 at 8:54 AM, Florian Margaine flor...@margaine.com
wrote:
Hi Ferenc,
Ferenc Kovacs tyr...@php.net writes:
Hello!
The PHP development team announces the immediate availability of PHP
5.6.6.
This release fixes several bugs and addresses CVE-2015-0235 and
AssertionExceptions are not intended to be caught, they are intended
to be seen, in a specific environment.
Joe, your argumentation is around how (not) to use exceptions. I can see
your point and it's valid.
My point is about not to implement exceptions at all.
If exceptions are not
hi Dmitry,
On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Larry,
Anthony, can you expand here at all about the practical benefits of
strong-typing for variable passing for the compiler?
On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye pierre@gmail.com wrote:
hi Dmitry,
On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Larry,
Anthony, can you expand here at all about
On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress
cryptocompr...@googlemail.com wrote:
AssertionExceptions are not intended to be caught, they are intended to
be seen, in a specific environment.
Joe, your argumentation is around how (not) to use exceptions. I can see
your point and it's
On Thu, Feb 19, 2015 at 7:00 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org wrote:
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
I totally miss the Expectation
Hi,
Le 20 févr. 2015 14:34, Ferenc Kovacs tyr...@php.net a écrit :
On Fri, Feb 20, 2015 at 8:54 AM, Florian Margaine flor...@margaine.com
wrote:
Hi Ferenc,
Ferenc Kovacs tyr...@php.net writes:
Hello!
The PHP development team announces the immediate availability of PHP
5.6.6.
This
Hi!
cc'ing Stas as he was the author for this change.
but from my understanding this isn't a problem as we disallow setting
multiple headers in a single header() call for years (even though we had
a regression at one point).
Well, we allowed multiline headers but it is an extremely exotic
Dmitry
On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye pierre@gmail.com wrote:
hi Dmitry,
On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara
Am 20.02.2015 um 15:09 schrieb Nikita Popov:
On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress
cryptocompr...@googlemail.com mailto:cryptocompr...@googlemail.com
wrote:
AssertionExceptions are not intended to be caught, they are
intended to be seen, in a specific environment.
Chris,
I'll edit in the proposal, but you can check the tests in the mean time:
https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_002.phpt
On 02/20/2015 06:28 PM, Anthony Ferrara wrote:
Considering I'm not targetting 7 (I've updated the RFC to hint this),
we can choose what to do later depending on the exceptions result
(whether to bypass execution in strict mode only, or for all calls).
Thanks for the insight Anthony
That
Hello
Am 20.02.2015 um 22:03 schrieb François Laupretre:
I just wonder why we need to prohibit these names. Can types not reside
in the global \ namespace? We could then change the class resolution
rules to allow to look also in \ as is done for functions currently.
Thanks
Dennis
This is
On 02/20/2015 07:54 AM, Niklas Keller wrote:
Hi internals,
In Operator is now in discussion phase.
This RFC adds a new in operator which simplifies contains checks for strings
and arrays.
Currently, we have to usein_array($needle, $haystack, true) or
strpos($haystack, $needle) !== false.
Larry,
On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield la...@garfieldtech.com wrote:
On 02/20/2015 06:28 PM, Anthony Ferrara wrote:
Considering I'm not targetting 7 (I've updated the RFC to hint this), we
can choose what to do later depending on the exceptions result (whether to
bypass
Robert,
On Fri, Feb 20, 2015 at 2:48 PM, Robert Stoll p...@tutteli.ch wrote:
Hi Dmitry and Anthony,
I was skimming through your conversation about JIT/AOT and that type hints
would allow to optimise few things.
I do not know if you are aware of the following but type hints can be passed
Hi,
as already threatened, I hereby open the vote on the pecl_http RFC.
https://wiki.php.net/rfc/pecl_http#vote
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
All,
An interesting point was brought up related to block mode:
https://twitter.com/drrotmos/status/568540722586107904
Namely that generated file caches may need the ability to switch block
mode on-and-off.
I'm considering making the change to add that. If that happens,
declare must be
On 02/20/2015 02:23 PM, Pierre Joye wrote:
On Fri, Feb 20, 2015 at 10:51 AM, Markus Fischer mar...@fischer.name wrote:
On 20.02.15 18:55, Sara Golemon wrote:
Announcing this in its own thread:
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
This RFC acts as an addition to Levi's
2015-02-21 1:07 GMT+01:00 Pádraic Brady padraic.br...@gmail.com:
On 20 February 2015 at 23:38, Larry Garfield la...@garfieldtech.com
wrote:
While I love the idea, strict type comparison for in would, in essence,
be a
toe-dip into the scalar strict typing world (see other thread) that
would be
Hi all,
On Sat, Feb 21, 2015 at 9:58 AM, Niklas Keller m...@kelunik.com wrote:
2015-02-21 1:23 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Hi all,
On Sat, Feb 21, 2015 at 2:55 AM, Sara Golemon poll...@php.net wrote:
Announcing this in its own thread:
Hi François,
Am 21.02.2015 um 03:03 schrieb François Laupretre:
I didn't consider defining builtin type hints as classes because :
I was not proposing using internal types as classes. I just want to
define a clean behavior for all kinds of types that may exist some time
in PHP. As no scalar
Hey Tom,
Patch looks solid (basically the same as the isset logic with OR
instead of AND). I think it's fairly sane to have this feature because
it compliments isset functionality (although I dislike empty
personally - consistency is nice)
No RFC would be complete without a complaint about
Hi all,
I think this will be the final discussion before vote.
This RFC is to make PHP stronger against script inclusion attacks just like
other languages.
https://wiki.php.net/rfc/script_only_include
I hope everyone will like this proposal.
Thank you all who have participated to discussions.
Hi Guys
on the point of new blood
I am new to internals therefore been going through some blogs, books,
slides, docs. I been trying to fix some bugs and commenting on some, I
would like to do something more get more involved.
I am not sure a procedure on getting new comers involved like
Hello Internals!
The following RFC aims to make empty() have a variable arity:
https://wiki.php.net/rfc/variadic_empty. This is a simple feature that enables
for a short-hand notation of checking multiple expressions for emptiness (which
is a pretty common thing to do).
I have avoided including
2015-02-21 1:23 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Hi all,
On Sat, Feb 21, 2015 at 2:55 AM, Sara Golemon poll...@php.net wrote:
Announcing this in its own thread:
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
This RFC acts as an addition to Levi's
Hi Crypto,
On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress
cryptocompr...@googlemail.com wrote:
AssertionExceptions are not intended to be caught, they are intended to be
seen, in a specific environment.
Joe, your argumentation is around how (not) to use exceptions. I can see
your point
On Fri, Feb 20, 2015 at 3:36 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Larry,
On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield la...@garfieldtech.com
wrote:
On 02/20/2015 06:28 PM, Anthony Ferrara wrote:
Considering I'm not targetting 7 (I've updated the RFC to hint this), we
can
Hi Larry,
That's OK. Let's remove 'resource'.
Anyway, I already explained why, IMO, the approach of reserving keywords is
flawed from the beginning. I'll explain again and propose an alternative in the
upcoming STH RFC.
Once we have a solution for the underlying issue with a planned
On 20 February 2015 at 23:38, Larry Garfield la...@garfieldtech.com wrote:
While I love the idea, strict type comparison for in would, in essence, be a
toe-dip into the scalar strict typing world (see other thread) that would be
very confusing. Consider:
if (3 in $_GET['filters']) { ... }
Hi all,
On Sat, Feb 21, 2015 at 2:55 AM, Sara Golemon poll...@php.net wrote:
Announcing this in its own thread:
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
This RFC acts as an addition to Levi's
https://wiki.php.net/rfc/reserve_more_types_in_php_7 by creating a
forum for
Hi Anthony,
I guess you would keep supporting __toString() ? So, you should probably
consider 'string' as 'string|object'.
Adding this case to 'float' meaning 'int|float' and 'callable' resolving to
'string|array|object', are you sure it's worth the pain implementing and
supporting a
Hi Dennis,
I didn't consider defining builtin type hints as classes because :
- I think it would be slower, and we need speed, but I agree, I did no test
- no pre-defined namespace exists to handle this
- Reverting to the root namespace makes it twice slower. The case of functions
is nothing
Hi Pierre,
De : Pierre Joye [mailto:pierre@gmail.com]
I do think we should. We are exactly at the point I was afraid to
reach with the unrealistic planning for 7. Engine is somehow stable
from an API changes point of view, so other can start to work on a
couple of key features. But it
To be harsh: All comments in favour of throwing exceptions here,
substantiate theirs needs with dead, never reached and potentially buggy
code.
The *changed code flow in production* is the big pitfall of this RFC and
an absolute no-go. I like zero-cost assertions but throwing exceptions
is
On Thu, Feb 19, 2015 at 11:13 PM, Kalle Sommer Nielsen ka...@php.net wrote:
2015-02-20 2:36 GMT+01:00 Levi Morrison le...@php.net:
int, integer
bool, boolean
true, false
float, double
I guess we should add 'real' here as well, since we still have the
(real) type cast and is_() type check
Hi,
First of all I'd like to see this (clean) RFC formalized / ratified
sooner rather than later.
Just to chime in here from a user / framework developer perspective in
regards to *double* / *real* / *boolean* / *integer* reservation: i'd
like to see these aliases (and the is_*-functions etc) be
On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote:
verification and static analysis aren't enough?
Anthony,
While IMHO they're not enough to warrant substantial deviation from PHP's
behavior, this is a subjective question that others might answer differently.
But
On Fri, Feb 20, 2015 at 3:45 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
cc'ing Stas as he was the author for this change.
but from my understanding this isn't a problem as we disallow setting
multiple headers in a single header() call for years (even though we had
a
However I think it is pre
mature to vote on as there was (sorry) not explicit discussions about
it.
I haven't heard that from anyone else, the RFC is plenty old.
A couple of things are unclear. See the numerous questions in this thread.
I also do not like other things.
These don't seem like
On Fri, Feb 20, 2015 at 7:29 AM, Joe Watkins pthre...@pthreads.org wrote:
However I think it is pre
mature to vote on as there was (sorry) not explicit discussions about
it.
I haven't heard that from anyone else, the RFC is plenty old.
A couple of things are unclear. See the numerous
On Fri, 2015-02-20 at 13:54 +0100, Niklas Keller wrote:
Hi internals,
In Operator is now in discussion phase.
This RFC adds a new in operator which simplifies contains checks for
strings and arrays.
Currently, we have to usein_array($needle, $haystack, true) or
strpos($haystack,
Hi,
On Fri, Feb 20, 2015 at 6:00 PM, Levi Morrison le...@php.net wrote:
On Fri, Feb 20, 2015 at 4:21 AM, Andrey Andreev n...@devilix.net wrote:
Agree on 'double' though ... if we want to discourage its usage, we
might even think of deprecating it.
While deprecating it might be a good course
So it is fine to have one setting doing the exact same thing? Sorry, I
disagree. We know we need that in other areas. Like other recent RFCs,
we have solved them bottom-up. This one is no different.
It's fine for an RFC to be focused on one thing. This is another subject.
So basically what
On Fri, Feb 20, 2015 at 4:21 AM, Andrey Andreev n...@devilix.net wrote:
On Fri, Feb 20, 2015 at 6:01 AM, François Laupretre franc...@php.net wrote:
Add 'resource', 'object', 'scalar', 'mixed', 'numeric'
If someone wants to reserve these I will leave them up to another RFC,
as I suspect they are
Zeev,
On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski z...@zend.com wrote:
On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote:
verification and static analysis aren't enough?
Anthony,
While IMHO they're not enough to warrant substantial deviation from PHP's
behavior,
On 21.02.15 06:11, Thomas Punt wrote:
Hello Internals!
The following RFC aims to make empty() have a variable arity:
https://wiki.php.net/rfc/variadic_empty. This is a simple feature that
enables for a short-hand notation of checking multiple expressions for
emptiness (which is a pretty
Hi Dennis,
Please give more precise examples. I'm afraid I don't understand :
If you use \ as prefix for builtin types, how do you distinguish this from
classes ? Would \resource mean the builtin type or a class name ?
Do you mean no class could be defined under \ ?
Syntax for union types ?
On Fri, Feb 20, 2015 at 8:36 AM, Joe Watkins pthre...@pthreads.org wrote:
No, we did not
Yes, we did, which you could have found out, if you were really bothered:
https://marc.info/?l=php-internalsm=138213285708117w=2
You are kidding me here and I already answered to that:
2013-10-18
On Feb 20, 2015 11:08 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Zeev,
On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski z...@zend.com wrote:
On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote:
verification and static analysis aren't enough?
Anthony,
Le Fri, 20 Feb 2015 13:54:26 +0100, Niklas Keller m...@kelunik.com a écrit:
Hi internals,
In Operator is now in discussion phase.
It would really make sense to vote on this RFC after there has been a
vote on https://wiki.php.net/rfc/context_sensitive_lexer.
Regards, Niklas
I agree. Context
On Fri, Feb 20, 2015 at 8:24 AM, Joe Watkins pthre...@pthreads.org wrote:
So it is fine to have one setting doing the exact same thing? Sorry, I
disagree. We know we need that in other areas. Like other recent RFCs,
we have solved them bottom-up. This one is no different.
It's fine for an RFC
De : Zeev Suraski [mailto:z...@zend.com]
So no, I don't think we're making a bigger deal out of it than it is.
Scalar type hints are a huge deal, and the fact you can emulate them in
userland code today doesn't change that in any way.
Agreed, of course, but I respectfully suggest you may be
Hi,
This driver returns all column data as a string, regardless of how it's
represented in the DB. I created a patch for my own use that syncs up the
type handling with the behavior of the MSSQL extension. This seems like it
would be of general use. Does anyone have any feedback before I put
No, we did not
Yes, we did, which you could have found out, if you were really bothered:
https://marc.info/?l=php-internalsm=138213285708117w=2
Cheers
Joe
On Fri, Feb 20, 2015 at 4:31 PM, Pierre Joye pierre@gmail.com wrote:
On Fri, Feb 20, 2015 at 8:24 AM, Joe Watkins
On 20 February 2015 at 15:55, Johannes Schlüter johan...@schlueters.de wrote:
On Fri, 2015-02-20 at 13:54 +0100, Niklas Keller wrote:
Hi internals,
In Operator is now in discussion phase.
This RFC adds a new in operator which simplifies contains checks for
strings and arrays.
Larry,
Assume for a moment that:
- we tighten up the default passing rules, such that 32 passed to an int
works but 32 footsteps errors (which I thing most are on board with doing)
- we include a strict types mode as proposed, including the logical type
widening cases
- Zend Engine gets
Hi,
This is not a question of namespace resolution. Built-in type hints and
namespaces have nothing in common.
It is just about the logic of :
Class resource {
...
}
Function foo(resource $arg, ...)
Do we check $arg to be I_RESOURCE or an instance of the 'resource' class ?
Hope I'm clear.
Hey folks,
Currently argument unpacking can only be used once in a call and only
after all positional arguments were passed.
E.g. func(1, 2, 3, ...[4, 5]) is allowed, but func(...[1, 2, 3], 4,
...[5]) is not.
This makes it impossible to use this feature with some of the ext/std
functions
On Fri, Feb 20, 2015 at 8:00 AM, Levi Morrison le...@php.net wrote:
On Fri, Feb 20, 2015 at 6:01 AM, François Laupretre franc...@php.net wrote:
Add 'resource', 'object', 'scalar', 'mixed', 'numeric'
If someone wants to reserve these I will leave them up to another RFC,
as I suspect they are
On 20 February 2015 at 04:54, Niklas Keller m...@kelunik.com wrote:
Question: The timline says Line up any remaining RFCs that target PHP
7.0., does that mean RFCs have to
start voting on Mar 15 or should the vote end there?
My interpretation was that votes had to be concluded on or before
Announcing this in its own thread:
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
This RFC acts as an addition to Levi's
https://wiki.php.net/rfc/reserve_more_types_in_php_7 by creating a
forum for voting on additional types not included in his RFC:
resource, object, scalar, mixed,
Hi Andrey,
I think the question of reserving 'resource' or not is not the main one.
The question of having to reserve keywords is much more fundamental and needs
to be addressed first. I expect it to be clear for everyone that, as long as we
share the same naming space between
On 19 February 2015 at 01:09, Joe Watkins pthre...@pthreads.org wrote:
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
Sorry, I had an e-mail backlog while this was in discussion, so I'm
only getting around to this now. Two thoughts:
1. This is
On Feb 20, 2015 8:11 AM, Andrey Andreev n...@devilix.net wrote:
Hi,
On Fri, Feb 20, 2015 at 6:00 PM, Levi Morrison le...@php.net wrote:
On Fri, Feb 20, 2015 at 4:21 AM, Andrey Andreev n...@devilix.net
wrote:
Agree on 'double' though ... if we want to discourage its usage, we
might even
On 20.02.15 18:16, Dan Ackroyd wrote:
On 20 February 2015 at 12:54, Niklas Keller m...@kelunik.com wrote:
Hi internals,
It would really make sense to vote on this RFC after there has been a
vote on https://wiki.php.net/rfc/context_sensitive_lexer.
That is an understatement:
On 02/20/2015 09:39 AM, Anthony Ferrara wrote:
I think if anything, the appearance of Hack (and its adoption) show
that people want static typing, at least to some level...
To be perfectly transparent here though, you should mention that your
proposed RFC goes well beyond the strict typing that
On 20.02.15 18:55, Sara Golemon wrote:
Announcing this in its own thread:
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
This RFC acts as an addition to Levi's
https://wiki.php.net/rfc/reserve_more_types_in_php_7 by creating a
forum for voting on additional types not included in
On 20.02.15 18:55, Sara Golemon wrote:
Announcing this in its own thread:
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
This RFC acts as an addition to Levi's
https://wiki.php.net/rfc/reserve_more_types_in_php_7 by creating a
forum for voting on additional types not included in
On Feb 20, 2015, at 10:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/20/2015 09:39 AM, Anthony Ferrara wrote:
I think if anything, the appearance of Hack (and its adoption) show
that people want static typing, at least to some level...
To be perfectly transparent here though, you
On Fri, Feb 20, 2015 at 9:26 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Anthony,
On Fri, Feb 20, 2015 at 5:55 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Dmitry
On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye
Point of clarification: it exists in the RFC already:
https://wiki.php.net/rfc/scalar_type_hints_v5#internal_functions_should_opt-in_to_typing
On Fri, Feb 20, 2015 at 2:06 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Rasmus,
To be perfectly transparent here though, you should mention that
On Fri, Feb 20, 2015 at 10:51 AM, Markus Fischer mar...@fischer.name wrote:
On 20.02.15 18:55, Sara Golemon wrote:
Announcing this in its own thread:
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
This RFC acts as an addition to Levi's
Hi Adam,
I would say that vote can *start*by March 15, as RFC is not supposed to evolve
after vote starts, hence 'feature freeze', but I have a personal interest there
because it would allow to vote on STH after people have enough time to compare
concurrent proposals, if there are. Otherwise,
On 02/20/2015 10:52 AM, Josh Watzman wrote:
On Feb 20, 2015, at 10:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
Hack examples all using ?hh // strict
echo number_format('1000');
echo htmlspecialchars(1000);
echo md5(1000);
These are all fine both as far as the type-checker is
1 - 100 of 106 matches
Mail list logo
