Re: [PHP-DEV] Annotations in PHP7
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 wouldn't be executed until an external mechanism decides to do so. So, this is PHP code and it is compiled and stored in memory besides the function opcodes, but not evaluated. Right. It's even not compiled into bytecode, just parsed into AST and then associated with function/class/property like doc-comment. You're right, it contains code. The key point is that this code will never be executed nor used in any way until an external mechanism decides to retrieve and evaluate it. That's metadata. Right again. Hi, thank you for the answers. I understand the anything is possible argument and would like to see/push future ideas in direction of domain-specific languages (DSL) opposite to another aspect-oriented programming (AOP) extension as in current examples. Sorry for offtopic. Thanks cryptocompress
[PHP-DEV] PHP 5.5.22 is available for downloads
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: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.5.22 Julien Pauli David Soria Parra
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
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? declare(strict_types=1) namespace Foo; namespace Bar; declare(strict_types=1) strict namespace Baz; Really good proposal though. Really hope it passes vote and we finally get scalar type hints in PHP. Cheers, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
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 reserve also. Hope 'null', 'true', and 'false' can technically be used as type hints. If not, bad news, especially for null. Love 'int|false' as return type ! I'd rather not reserve 'resource'. Such a hint may be useful in the short term, but there already are plans to turn the current resources into objects, and with the rise of REST lately it is also an obvious base class/interface/trait name. Agree on 'double' though ... if we want to discourage its usage, we might even think of deprecating it. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 nice, in my opinion. It's not about runtime, and the ability to catch specific exceptions by name, at all, there shouldn't be any catch blocks for AssertionExceptions in deployed code. Cheers Joe On Fri, Feb 20, 2015 at 11:06 AM, Leigh lei...@gmail.com wrote: 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 Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Nightmares on type hints, annotations, and aop...
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. It's been known for years that strict hints are is_*() else error equivalent, that weak hints are (mostly) just casts, etc. Saying the class type hints can be emulated with is_a() calls wouldn't shock anybody either. I think I may have realised just why *I* am having a problem with a lot of this discussion ... I've used ADOdb from day one which already does this ... *I* had not realised that core PHP did not bother with the management of data types that ADOdb is layering on top ... Hence my question yesterday which I will reword ... If PHP creates a new variable what does it store by default? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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
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 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 before..
I voted without custom exception, that is because.
if all assertion exception is AssertException, then we can simply
optimized them away while zend.assert is disabled..
like:
try {
foo();
bar();
assert();
} catch (AssertException $e) {
//these statements can be optimized away.
}
but with custom exception..
try {
sqllitefunc(); // no threw
sqllitefunc1(); //no threw
assert(, new SqlLiteException());
} catch (SqlliteException $e) {
//we are not sure maybe sqllitefunc can throw SqliteException.
// thus we can not optimized these statements ayway
}
thanks
Cheers
Joe
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Re: [PHP-DEV] [VOTE] Expectations
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 zero-cost, assert() won't be compiled at all (including inner code) zend.assertions=0 low-cost, assert() will be compiled but won't be executes (including inner code) zend.assertions=1 assert() wiil be compiled and executed as now Pardon me, but it doesn't explain what the role of the existing assert_options() function will or does play? - the RFC says: enabled (zend.assertions=1) on development machines, and disabled (zend.assertions=0) in production; a few paragraphs above it says -1 - don't generate any code (zero-cost, production mode). Shouldn't be -1 the default value for production then? With zend.assertions=0 in production, you'll able to switch to zend.assertions=0 at any time. With zend.assertions=-1 of course not. I don't understand this. With 'foo' in production, you will be able to switch to 'foo' at any time. With 'bar' of course not ? Maybe I was unclear. What I meant: - a few paragraphs above it says that -1 doesn't generate any code (zero cost) - so why isn't THAT '-1' promoted to be the default in production php.ini instead of '0' setting? - the RFC says: A call to assert(), without a fully qualified namespace will call assert in the current namespace, if the function exists. An unqualified call to assert is subject to the same optimization configured by zend.assertions. . Does this mean I can control whether a function in a namespace is being optimized-away with when zend.assertion equals -1 and otherwise do my own stuff in there and need to raise an AssertException on my own to signal assertion fails? Yes. you are able to eliminate your own assert() functions in namespaces. Wow. The RFC doesn't explain this very well but I wrote this based on assumption and guesswork. 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. With utter magic I mean: suddenly a function named 'assert' in a namespace is eligible to rules before ever only applied to a global existing function. I'm not saying it's bad. It's just very magic, sounds cool but could be a real PITA. Maybe just a documentation problem after all. As Pierre already mentioned, the RFC really lacks some more details. But in general, it looks good. thank you, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 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 before..
I voted without custom exception, that is because.
if all assertion exception is AssertException, then we can simply
optimized them away while zend.assert is disabled..
like:
try {
foo();
bar();
assert();
} catch (AssertException $e) {
//these statements can be optimized away.
}
but with custom exception..
try {
sqllitefunc(); // no threw
sqllitefunc1(); //no threw
assert(, new SqlLiteException());
} catch (SqlliteException $e) {
//we are not sure maybe sqllitefunc can throw SqliteException.
// thus we can not optimized these statements ayway
}
thanks
Cheers
Joe
--
Xinchen Hui
@Laruence
http://www.laruence.com/
[PHP-DEV] [RFC][PRE-VOTE] pecl_http
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
Re: [PHP-DEV] [RFC] Comparable: the revenge
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 work:
class A implements Comparable {
public $value;
function compareTo($other) {
if ($other instanceof A) {
return $this-value = $other-value;
} else {
return -1;
}
}
}
class B implements Comparable {
public $value;
function compareTo($other) {
if ($other instanceof B) {
return $this-value = $other-value;
} else {
return -1;
}
}
}
$a = new A();
$a-value = 1;
$b = new B();
$b-value = 2;
$a-compareTo($b); // -1
$b-compareTo($a); // -1
If you now have a mixed list of objects of A and B, the actual order in
the list completely depends whether A's compareTo() method is called or
B's compareTo() method.
I think comparison should always be symmetric:
$a $b = $b $a
Otherwise the behavior is nearly unpredictable/random.
As we have no method overloading, the only viable option I see is to
only allow comparison of objects of the same type.
Thanks
Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
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 everywhere, but this would present a huge BC break. If it were possible get these functions to throw an exception ONLY when they are included in a try ... catch block then this would not break BC at all. Tony, first of all - this still breaks BC, because exception is being thrown in a place where it used not to be... When some function's result heavily depends on the context it makes said function much harder to reason about. And creates mental overhead for those who'll have to read the code with this function. And again, if you need exceptions for fopen please consider using SplFileObject. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 before..
I voted without custom exception, that is because.
if all assertion exception is AssertException, then we can simply
optimized them away while zend.assert is disabled..
like:
try {
foo();
bar();
assert();
} catch (AssertException $e) {
//these statements can be optimized away.
}
but with custom exception..
try {
sqllitefunc(); // no threw
sqllitefunc1(); //no threw
assert(, new SqlLiteException());
} catch (SqlliteException $e) {
//we are not sure maybe sqllitefunc can throw SqliteException.
// thus we can not optimized these statements ayway
}
thanks
Cheers
Joe
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 then my ordinary syntax check run before deployment, could catch them :) ??? best regards Patrick
Re: [PHP-DEV] [RFC] Exceptions in the engine
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 10:52:
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
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('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error
message (it
could be a permissions error, for example). Is there any plan to
convert
procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
That is why I suggested that those functions could be made to switch between
throwing an exception or not based on them being included within a try ...
catch block (or not)
So, no, since that's currently an E_WARNING, there is no current
plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications
of
changing something from non-fatal to fatal are rather drastic.
Currently the only values returned by fopen(), fwrite() and fclose()
indicate either success or failure, but not the reason for any failure.
That has absolutely nothing to do with OO vs procedural code,
though.
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 everywhere, but this
would present a huge BC break. If it were possible get these functions to
throw an exception ONLY when they are included in a try ... catch block then
this would not break BC at all.
--
Tony Marston
A procedural function could well have an error condition which
should be
fatal if unhandled, but can usefully be caught somewhere up the
stack,
which is basically what an exception is for. Any procedural function
which
currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to
be
converted under the current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the
difficulty
with capturing the error message if it fails - is that it also exists
with
some other functions as well, so it would be nice to be able to put
the
function in a try . catch block so that any and every message
could be
made available. It is quite obvious that changing fopen() to use
exceptions
would be a major BC break for all exiting applications, so my
question is
this:
Would it be possible to tell the function if it were being called in
a
try ... catch bloc or not? If it were then throw an exception, if not
then
don't throw an exception. I realise that this might be tricky to
implement,
but if it could be it would allow the developer to choose whether
he/she
wanted to use exceptions or not instead of having the choice forced
upon
him/her.
Is this possible? Or am I just dreaming?
The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call in a try ... catch block
for
the purposes of that check, or not? If putting try { ... } around an
entire
application caused all calls to fopen(), in every library it used, to
stop
returning false, you'd have exactly the same BC issue as just changing
it
permanently.
function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}
function load_data() {
$fh = fopen(...);
...
}
So no, I'm afraid it's probably not possible.
Could it be restricted to the current scope? In your example the call
to
fopen() exists in the load_data() function and is not in a try ...
catch
block within *that* function, so the fact that the call to load_data()
is
within a try ... catch block should be irrelevant as it is in a
different
scope.
If the exception is only thrown when the try - catch is in the same
scope, is there really much advantage to it being an exception? When
you're
that close to the code, sticking an if ( $fh === false ) { ... } around
it
really isn't that much different from catch(IOException $e) {
The advantage is that you can obtain the reason for the error. All that
happens with fopen() at the moment is that it returns FALSE which tells
you
that it has failed, but it does not tell you why. This is a classic
example
of the semipredicate problem for which exceptions were originally
designed.
The main advantage is the ability to catch FATAL errors that previously
leaded to script termination and 500
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
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 yohg...@ohgaki.net wrote: Hi all, On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com wrote: I think that naming the new parent exception something like Throwable or Catchable (as Nikita previously suggested) would be a bit more concise in meaning than BaseException. You may not have even meant that name as a formal proposal, but I figured I'd weigh in regardless. :P I think they probably should use namespace... I meant users should use namespace to avoid namespace collisions... We may introduce PHP namespace for us to use. I'm +1 for this. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Comparable: the revenge
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: https://wiki.php.net/rfc/comparable PR: https://github.com/php/php-src/pull/1097 Afaik \DateTime object already implement a way to be used with ,,etc. but they don't use an interface for that. $ php -r '$past = new DateTime(-1 month); $future = new DateTime(+1 month); var_dump($past $future);' bool(true) $ php -r '$past = new DateTime(-1 month); $future = new DateTime(+1 month); var_dump($past $future);' bool(false) Shouldn't they retroactively be adopted to that? Extend from that Interface, implement a compoareTo? - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC][Discussion] In Operator
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 order, so it's hard to remember which is the right one for each. The in operator makes these checks way more readable. Additionally, it also works for Traversable. https://wiki.php.net/rfc/in_operator 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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
Re: [PHP-DEV] [RFC] Comparable: the revenge
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 vote was likely to fail. RFC: https://wiki.php.net/rfc/comparable PR: https://github.com/php/php-src/pull/1097 Why reanimate it now, I hear you ask? I think that comparisons have only become more prominent in the language: we now have a spaceship operator for explicit comparisons, yet the behaviour of object comparisons can be obscure, to say the least, and the user has no control over how their objects are compared. At this stage, I intend to put this up for a vote on March 5 (vote ending March 12), with the obvious endgame being that this would be included in 7.0. Some technical notes on the RFC text: * How it is ensured that if $a $b then $b $a? The RFC claims that it is up to the developer to ensure this, however I don't think this is true. As far as I know PHP will implicitly enforce this. It would be good if you could double-check the behavior. * If both $a and $b are objects with different compare functions, how it is determined whose function is used Here you answer that the left operand wins. Once again I am unsure whether this is true - I'd assume that for and = the right operand wins. * I would appreciate a note that indicates how non-total / non-trichotomous comparisons can be implemented, namely by returning 1 irregardless of order. You can use a subset-relationship to illustrate this. * Have you considered the impact on exception-safety this may have? Did you verify that all places where compare_function (or derivatives) are used are exception-safe? Nikita
Re: [PHP-DEV] [VOTE] Expectations
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 actually dead in production. So you just don't deploy catch blocks for AssertionException, you might write one while debugging locally, but deploying them doesn't make sense. Cheers Joe On Fri, Feb 20, 2015 at 1:05 PM, Crypto Compress cryptocompr...@googlemail.com wrote: 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
Re: [PHP-DEV] [RFC][DISCUSSION] Context Sensitive lexer
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: https://github.com/php/php-src/pull/1054
PHP currently has ~64 globally reserved words. Not infrequently, these
reserved words end up clashing with legit alternatives to userland API
declarations. This RFC proposes minimal changes to have a context sensitive
lexer with support for semi-reserved words on PHP7 without causing
maintenance issues.
This could be especially useful to:
- Reduce the surface of BC breaks whenever new keywords are introduced
- Avoid restricting userland APIs. Dispensing the need for hacks like
unecessary magic method calls or prefixed identifiers.
The patch is 98% finished, the entire test suite is passing. I'm still
adding more tests to it but the hard part is done. So it's time to discuss!
Sincerely,
Márcio Almada
I think we all agree that it would be nice to not be so strict about
reserved keywords in some places. As such this RFC hinges on questions of
implementation.
The RFC uses a purely lexer-based approach, which is nice in principle,
because ext/tokenizer benefits from it as well.
The disadvantage of doing this in the lexer and in the scope that you're
proposing (i.e. including class names) is that it requires reimplementing
quite a number of parser rules via lookahead in the lexer. This means that
a) the implementation depends on a complete understanding of the PHP
syntax, otherwise we'll miss edge cases or be too strict in others and
b) may limit us in future, because we may not be able to introduce syntax
that can't be reasonably recognized with simple lexer state management or
lookahead.
To give you an example of a), your patch currently handles a single
interface name properly
nikic@saturn:~/php-src$ sapi/cli/php -r 'class Foo implements Interface {}'
Fatal error: Interface 'Interface' not found in Command line code on line 1
but fails as soon as you implement multiple interfaces:
nikic@saturn:~/php-src$ sapi/cli/php -r 'class Foo implements Interface,
Array {}'
Parse error: syntax error, unexpected 'Array' (T_ARRAY), expecting
identifier (T_STRING) or namespace (T_NAMESPACE) or \\ (T_NS_SEPARATOR) in
Command line code on line 1
So, I'm sure this can be worked around with a couple of new lexer rules,
I'm just trying to show the systematic issues of this approach.
An example for b) is harder to come by (as I'm not terribly familiar with
what we can easily detect in the lexer and what we can't). One thing that
comes to mind is supporting a short lambda syntax like the one available in
Hack:
(ClassName $a, $b, $c, $d) == $a
As this has no prefixing function or similar, I suspect that it may be
rather hard to detect that ClassName is actually a class name here and
requires special treatment. Un-reserving class names now may make features
like this impossible (or unnecessarily hard) to implement in the future.
Due to these issues, I don't like the RFC in the current form - I think
it's too ambitious. Class names simply occur in too many and diverse places.
I would suggest going with a more limited approach instead, which targets
only method and class constant names. I.e. the label after - and :: should
not be reserved (we already do this for -) and the label after function
and const shouldn't be either. Of course this would also allow defining
global reserved-keyword function/const names as well, so we might want to
check their names against the list of reserved keywords. Though even that
is just a courtesy to the user, e.g. it's already possible to define and
access reserved-keyword constants using define() and constant().
Nikita
Re: [PHP-DEV] [VOTE] Expectations
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 especially for new developers. The alternatives are not nice, in my opinion. It's not about runtime, and the ability to catch specific exceptions by name, at all, there shouldn't be any catch blocks for AssertionExceptions in deployed code Hello Joe, can you please explain a bit more how you would achieve this in 3m loc? Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.6.6 is available
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 CVE-2015-0273. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.6 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.6.6 Taken from the changelog: Removed support for multi-line headers, as the are deprecated by RFC 7230. Isn't this a BC break? Ferenc Kovacs Julien Pauli Cheers, -- Florian Margaine 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). the current change was made to address https://bugs.php.net/bug.php?id=68978edit=1 which was an IE specific problem which was allowed by header(). maybe we should re-word the NEWS entry to make this a bit more clear.
Re: [PHP-DEV] [VOTE] Expectations
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 intended to be caught, they don't need to be thrown (even if the context is different). If exceptions are not thrown and not caught, we can use error in dev and some easing severity (warning, zero cost nothing) in prod. Freely adapted from Murphy: If assertion exception can be catched, it will be even in production. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. I think we can agree on that, and we did as far as I can tell :) However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Completely agree, changing language for compiler is not fair. It's clear that statically typed languages are more suitable but we won't make PHP statically typed. Also, modern JS engines showed - what they may do without typing. Let put things correctly please: In my opinion strict type hints may be useful for program verification, but again, I wouldn't like to change the whole language semantic We are talking about arguments handling here. Not the whole language semantic. The way the language works will stay the same. I am not writing that for you but for all other who may be misinterpret your reply. just to get few unit tests out of the box. Strict types handling for arguments goes way beyond having a few units tests. It would very good if one single point of the argumentation is used to generalize a cons argument. That makes no sense and it simply goes down a way I would really not like to see again. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. What is significant? Miracle ability of static analyzes for AOT? I think we can agree on that, and we did as far as I can tell :) I didn't agree with you. Probably, I told that performance impact of run-time switch of type hinting semantic is slightly negative and it would be great to fix it if possible. However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Completely agree, changing language for compiler is not fair. It's clear that statically typed languages are more suitable but we won't make PHP statically typed. Also, modern JS engines showed - what they may do without typing. Let put things correctly please: In my opinion strict type hints may be useful for program verification, but again, I wouldn't like to change the whole language semantic We are talking about arguments handling here. Not the whole language semantic. The way the language works will stay the same. I am not writing that for you but for all other who may be misinterpret your reply. just to get few unit tests out of the box. Strict types handling for arguments goes way beyond having a few units tests. It would very good if one single point of the argumentation is used to generalize a cons argument. That makes no sense and it simply goes down a way I would really not like to see again. I didn't hear any arguments for strict typing except for program verification and static analyzes, may be I missed. Please, tell me few use cases, may be it'll change my mind :) Thanks. Dmitry. Cheers, -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] [VOTE] Expectations
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 valid. My point is about not to implement exceptions at all. If exceptions are not intended to be caught, they don't need to be thrown (even if the context is different). If exceptions are not thrown and not caught, we can use error in dev and some easing severity (warning, zero cost nothing) in prod. Freely adapted from Murphy: If assertion exception can be catched, it will be even in production. The point behind AssertionException is that a) It will leave the scope where with the failed assertion immediately. A warning would continue running the code, even though some precondition is violated, which doesn't make sense. b) It can still be gracefully handled (unlike a fatal error). E.g. the unit testing framework can catch it, so you can continue running all your tests even if one causes an assertion failure. When Joe says not intended to be caught this is referring to normal code. Catching them at the top-level still makes sense, e.g. for the unit testing case mentioned or even just to print a nice error message with extra information. Using an exception instead of a fatal error also means that things like finally will still run, so your code can still release locks etc even if an assertion failure occurred. Nikita
Re: [PHP-DEV] [VOTE] Expectations
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 RFC announcement. Where the RFC was actually proposed for discussions. I have been following up the DbC thread, seeing some mentions but that's it. The RFC itself popped up 3 days ago. Also the RFC itself only point to various discussions, there is no summary, details, docs, examples, etc in the RFC. I am sorry but as much I like (for what I think it does) as I like the concept, this RFC does not have, by far, the quality I would expect for a RFC being voted on. Coming back to this point. I very much like what is presented here. However I think it is pre mature to vote on as there was (sorry) not explicit discussions about it. A couple of things are unclear. See the numerous questions in this thread. I also do not like other things. zend.assertions: I understand we need to be able to disable them. Is production vs development/debug mode specific to assertion? I do not think so, we should have a more general setting for that so other areas can be used for it. INI_SYSTEM may also reduce the usage of this feature to local development or dedicated hosts. Any shared hoster (those not allowing to change php.ini) won't be able to test in similar tests environment. It is not critical but it is something you may reconsider. assert.exceptions: Let solve the exception usages in the engine first and see how to deal with them more globally, including naming, NS or where and how they can be used. This is in my eyes a pre requise to this RFC. INI_ALL is used here. That means that just like error_reporting (which is actually very painful), calling some random codes may makes my code (caller) raised exceptions when I do not want to, or the other way round? I am not too keen on that idea. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.6.6 is available
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 release fixes several bugs and addresses CVE-2015-0235 and CVE-2015-0273. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.6 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.6.6 Taken from the changelog: Removed support for multi-line headers, as the are deprecated by RFC 7230. Isn't this a BC break? Ferenc Kovacs Julien Pauli Cheers, -- Florian Margaine 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). the current change was made to address https://bugs.php.net/bug.php?id=68978edit=1 which was an IE specific problem which was allowed by header(). maybe we should re-word the NEWS entry to make this a bit more clear. Fair enough then. The changelog makes it look like a BC break without any reason. Cheers, Florian Margaine
Re: [PHP-DEV] PHP 5.6.6 is available
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 feature which is now dropped from the HTTP/1.1 standard, and also it causes security issues with IE users since IE never supported that feature properly. So given that I've decided to remove it even though strictly speaking it is a BC break (same goes for the HTTP standard). -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 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? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. What is significant? Miracle ability of static analyzes for AOT? Please, can we discuss something without snark? And can we get past AOT? It's distracting. I only mentioned it here because I was specifically asked about it. It's not in my RFC. So please, let's get past it. I think we can agree on that, and we did as far as I can tell :) I didn't agree with you. Probably, I told that performance impact of run-time switch of type hinting semantic is slightly negative and it would be great to fix it if possible. Everyone is saying this shouldn't be voted on based on performance. You, me, Pierre, everyone. Additionally, the negative impact could be solved by introducing a new opcode for scalar checks, pushing any performance difference to compile time. But I'd like to see some measurments of the performance difference prior to going down that road. In short, the negative performance difference is either going to be negligible (won't appear on a benchmark) or can more than likely be made negligible without a terrible amount of work. However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Completely agree, changing language for compiler is not fair. It's clear that statically typed languages are more suitable but we won't make PHP statically typed. Also, modern JS engines showed - what they may do without typing. Let put things correctly please: In my opinion strict type hints may be useful for program verification, but again, I wouldn't like to change the whole language semantic We are talking about arguments handling here. Not the whole language semantic. The way the language works will stay the same. I am not writing that for you but for all other who may be misinterpret your reply. just to get few unit tests out of the box. Strict types handling for arguments goes way beyond having a few units tests. It would very good if one single point of the argumentation is used to generalize a cons argument. That makes no sense and it simply goes down a way I would really not like to see again. I didn't hear any arguments for strict typing except for program verification and static analyzes, may be I missed. Please, tell me few use cases, may be it'll change my mind :) verification and static analysis aren't enough? Seriously, equating static analysis to a few unit tests is either un-unnecessarily hyperbolic or a complete misconsurance of the point. Unit tests at best tell you that the code behaves as the tests say. Those tests can be bogus, but the tests still pass. Static analysis on the other hand can tell you if the code is semantically correct or not (whether or not errors can/will be thrown). The type system provides a lower bound on correctness. The unit tests at best establish an upper bound.
Re: [PHP-DEV] [VOTE] Expectations
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. 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 intended to be caught, they don't need to be thrown (even if the context is different). If exceptions are not thrown and not caught, we can use error in dev and some easing severity (warning, zero cost nothing) in prod. Freely adapted from Murphy: If assertion exception can be catched, it will be even in production. The point behind AssertionException is that a) It will leave the scope where with the failed assertion immediately. A warning would continue running the code, even though some precondition is violated, which doesn't make sense. Assumed context is wrong here. - exception in development: error - no exception in production: warning, zero cost nothing Rephrased: A zero-cost non-existing exception would continue running the code, ... In a previous email you brought up the point if or not derive AssertionEx from Exception. I argue that all child exception MUST BE derived from Exception. Any exception to this is not an Exception. (my english is too limited to explain this, sorry) b) It can still be gracefully handled (unlike a fatal error). E.g. the unit testing framework can catch it, so you can continue running all your tests even if one causes an assertion failure. Unit test frameworks do this already. No change here. When Joe says not intended to be caught this is referring to normal code. Catching them at the top-level still makes sense, e.g. for the unit testing case mentioned or even just to print a nice error message with extra information. Using an exception instead of a fatal error also means that things like finally will still run, so your code can still release locks etc even if an assertion failure occurred. In production this will never happen. We go round in circles here. I am aware of you preference on exceptions everywhere. Nikita
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
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 https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_004.phpt https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_005.phpt So it needs to come before the namespace declaration (in fact, it currently needs to be the first declaration in the file). Though I am about to implement the block syntax, and that may alter things slightly (though declare will be required to be outside the namespace). Anthony On Fri, Feb 20, 2015 at 6:07 AM, Chris Harvey ch...@chrisnharvey.com wrote: 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? declare(strict_types=1) namespace Foo; namespace Bar; declare(strict_types=1) strict namespace Baz; Really good proposal though. Really hope it passes vote and we finally get scalar type hints in PHP. Cheers, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 makes me very sad, as whether the strict option is there or not I'd *really* love to see scalar hints in PHP 7 to complement return type hinting. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 not a question of namespace resolution. Built-in type hints and
namespaces have nothing in common.
I do not know how the actual implementation works, but I assume there is
a symbol table for each namespace that contains a list of
class/trait/interface names for that namespace. Why not enhance this
mechanism to contain all type information for each namespace? Simple
types go into that symbol table, type aliases, type defs/enum types (if
such a thing gets implemented), union types, etc. In addition, if the
current namespace symbol table does not contain an entry (and the
autoloader fails), the root namespace is tested for a name.
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 ?
The class definition would give an error, as resource already exists
in the topmost namespace.
namespace test {
Class resource { ... }
function foo(resource $arg, ...)
}
function bar(resource $arg, ...)
foo uses the class test\resource, bar uses the resource type from the
root namespace.
Maybe PHP works completely different internally and this is not
feasible. But reserving some names from being valid as a class name
sounds like a hack, I would prefer a clean and generic solution.
Thanks
Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] In Operator
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.
These functions have a inconsistent parameter order, so it's hard to remember
which is the right one
for each. The in operator makes these checks way more readable. Additionally,
it also works for Traversable.
https://wiki.php.net/rfc/in_operator
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?
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
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']) { ... }
That would always be false, because $_GET is always strings. To make
that work I'd need to first cast all of the elements in that array to
ints... which I'm not actually sure how to do cleanly.
I'd much rather we tighten up the rules around implicit casts generally,
as discussed elsewhere, and then allow those loose but not as loose as
we have now rules here.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 execution in strict mode only, or for all calls). Thanks for the insight Anthony That makes me very sad, as whether the strict option is there or not I'd *really* love to see scalar hints in PHP 7 to complement return type hinting. Timing just won't work while being fair with alternative proposals. I've said since I re-opened the proposal that I'm comfortable with it not targeting 7.0... Unless we're willing to push feature freeze by 2-3 weeks for it, it just doesn't make sense to target 7 with people working on an alternate proposal (since by definition they couldn't target 7). Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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
by. Hence neither weak or strict type hints allow to predict the type (even
if only locally):
function handler($errno, $errstr, $errfile, $errline){
return true;
}
set_error_handler(handler);
class Foo{}
function foo(int $x, Foo $f){
var_dump($x, $f);
$y = $x; //should be int as well, right?
}
foo(new Foo(), 1);
Sure, this is something which is hopefully never ever done but anyway, a
language needs to be able to handle all cases.
As a side notice, if the exceptions in the engine RFC is accepted, then this
would not be a problem anymore:
https://wiki.php.net/rfc/engine_exceptions_for_php7
Personally, I would expect that the execution is stopped after the
error_handler was called (after user was able to log etc.) - at least in
strict mode.
That's a very good point.
Ideally exceptions will help there as it will simplify things
significantly. But even without them, it should be possible to bypass
execution.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC][VOTE] pecl_http
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
[PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
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 the outermost block, and no non-declare blocks would
be allowed in the outermost scope of the file:
?php
declare(strict_types=1) {
//...
}
declare(strict_types=0) {
//...
}
Having trailing code or code outside of the declare would be a compile error.
?php
declare(strict_types=1) {
//...
}
foo(); // compile error
This behaves consistent with namespace block-mode today (though the
strict type declaration would be required to be outside the namespace
block).
I'm considering adding it, as it's a valid use-case. What do you think?
So, I ran into a snag while doing this.
It turns out that in the parser implementation of declare is not going
to allow it without significant restructuring (including a lot of
validation in the compiler):
declare_statement:
statement { $$ = $1; }
| ':' inner_statement_list T_ENDDECLARE ';' { $$ = $2; }
;
So in block mode, declare supports inline, block and named-block mode:
declare(...) foo();
declare(...) {
foo();
}
declare(...):
foo();
enddeclare;
The problem with this is that namespace declarations can only happen
in top_statement (along with some other statements).
That leaves two options to support multiple modes per file:
1. Allow in top-level only:
declare(strict_types=1);
namespace Foo {
}
declare(strict_types=0);
namespace Bar {
}
2. inside of the namespace:
namespace Foo {
declare(strict_types=1);
}
namespace Bar {
}
The problem with the first is clarity (it's easy to miss a declare and
not understand that the mode has changed). We pinned declare to the
top of the file for clarity. I'm not sure this use-case is worth
breaking that clarity.
The problem with the second is more subtle. With the current
parser+compiler, that declare would affect the entire file. It would
take pretty significant changes and restructuring of the parser to
effect.
We could drop declare() all together and go with something like a
namespace modifier:
strict namespace Foo {
}
namespace Bar {
}
But I don't think it's worth it to conflate those two together. Though
if we did, the syntax strict namespace; would be supported for
non-namespaced strict code.
So in the end, my conclusion is that while it would be nice to support
the compiled file use-case fully, it's not worth it from a technical
level (the risk and degree of change required doesn't offset the
benefit of it).
So the proposal will remain unchainged and not support the block
syntax (or changing the mode mid-file).
Thanks
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 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, numeric From the RFC: “resource” “object” “scalar” “mixed” “numeric” ... prohibits their usage as class, interface and trait names. This is such a major BC break. One thing we must do before even considering non required names is to actually check every major apps, frameworks or libraries. If we can avoid a date/datetime clash again, that would be awesome ;) resource is problematic as that is the proper name for the thing that corresponds to a URL in REST. I would be shocked if there aren't classes named Resource (namespaced or not) floating around in web services code. I actually started writing one myself at one point on the side but got distracted by something else shiny... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] In Operator
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
very confusing. Consider:
if (3 in $_GET['filters']) { ... }
That would always be false, because $_GET is always strings. To make
that
work I'd need to first cast all of the elements in that array to ints...
which I'm not actually sure how to do cleanly.
You need casting anyway if comparing raw GET/POST directly to any
integer as a decision point on whether to use the raw value, i.e. it's
unvalidated otherwise and could have been 1234script[...].
Yes, I'm abusing your intentionally very simple example. There are
other cases away from user input where looser comparisons wouldn't
have the same potential issues with non-permanent type juggling. I
would be a huge fan of having it be strict since the above, while
clearly a simple example, has been problematic in the past for
validation routines and, as a security guy, I'm obsessed with that ;).
Also, on toe-dipping into strict typing, I think your opinion may be
slightly overweight towards that topic given recent RFC history - we
already have === as our toe in the water.
I'd much rather we tighten up the rules around implicit casts generally,
as
discussed elsewhere, and then allow those loose but not as loose as we
have
now rules here.
I could work with that perhaps. RFCs of this type are in a bit of a
bind while we wait for scalar typehints/potential casting rules to be
finalized in some form. It also appears unlikely that in as the
operator name will pass muster if the context sensitive lexer RFC does
not pass, i.e. would break uses of in() as a method name.
Niklas, any chance you have considered a Plan B for the operator
naming? Mostly curious if these is already some alternative outside of
the field of langs I'm familiar with that might be acceptable.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
if (3 in $_GET['filters']) { ... }
That would always be false, because $_GET is always strings. To make that
work I'd need to first cast all of the elements in that array to ints...
which I'm not actually sure how to do cleanly.
You could easily cast the left operand to a string instead.
I'd much rather we tighten up the rules around implicit casts generally, as
discussed elsewhere, and then allow those loose but not as loose as we
have now rules here.
Maybe I'd be OK with that then, but not in the state we currently have. I
think a change here would be too rushed and would therefore have to wait
until PHP 8.
Niklas, any chance you have considered a Plan B for the operator
naming? Mostly curious if these is already some alternative outside of
the field of langs I'm familiar with that might be acceptable.
Not really. It could be named `contains`, but that would create the same
problems.
It also appears unlikely that in as the
operator name will pass muster if the context sensitive lexer RFC does
not pass, i.e. would break uses of in() as a method name.
You're totally right. It's already the second RFC on that topic (
https://wiki.php.net/rfc/keywords_as_identifiers is the other one I know).
If context sensitive lexer doesn't parse, in may have to wait until PHP
8, which may have another RFC here.
Regards, Niklas
Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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: 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, numeric We should have reserved these. IMHO. Yes, it breaks. However, sooner is better. People don't just use PHP7. We may try to promote these changes now. We still have time. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net Resource is used quite often: https://github.com/search?l=phpq=class+Resourceref=searchresultstype=Codeutf8=%E2%9C%93 Unfortunately, GitHub doesn't allow a search for class Resource for better results. Google knows about 600 occurrences: https://www.google.de/?#q=site:github.com+%22class+resource%22+php One more popular example usage: https://github.com/phacility/phabricator/blob/master/externals/balanced-php/src/Balanced/Resource.php Just to throw some numbers in. We may buy some time. We may announce it by PHP 7.0. (E_STRICT perhaps?) Introduce new reserved words in PHP 7.X. (E_ERROR/E_COMPILE_ERROR whichever is appropriate) Sooner announcement is better, then introduce. It would work better. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 type hints RFC has passed so far, we could also define it in a clean way and just put the scalar types into \, then we can not have the conflicting classes there and have to use function foo(\int $c) instead of function foo(int $c) which is a lot better that switching type hints for classes to something like function bar (object(my\namespaced\class) $a). - I think it would be slower, and we need speed, but I agree, I did no test I don't know this. - no pre-defined namespace exists to handle this There is \ - Reverting to the root namespace makes it twice slower. The case of functions is nothing more than a hack to have a flawed design approved by all means. Also you could just use \int, \string; on top of the file, than function foo(int $c) is ok. In total, I think that is the BC-break safe way to go, it will keep the door wide open for union types, etc. without the worry of BC breaks. We could leave out all the hacky stuff here. We could even use \PHP as the namespace to go. - Storing builtin types in the root namespace would cause exactly the same problem of sharing a naming space with user-defined names. No, because you can just move you classes into a namespace and add some use statements to the top of the consumer files (with different namespaces in use). With the current proposals, you have to invent new names for you classes. - and probably the most important one: the implementation is based upon the ZPP layer, which allows internal and userland type hinting to follow exactly the same logic. I consider this a detail that should not prevent a clean language design. It may mean more work in the short time but I think this will greatly increase the adoption rate if we can eliminate the BC break here. About namespaces : no type hinting feature is currently planned at the namespace level, except the usual class resolution when a class name is used as hint. Some may exist in the future as there will probably be more links between built-in types and classes, such as specializing and combining builtin types using a userland class or exposing builtin-types as classes. Thanks Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Make empty() a Variadic
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 naming. empty_expressions ... I'll give you an empty expression! But overall +1 on functionality and patch. Cheers! Leigh. On 21 February 2015 at 05:11, Thomas Punt tp...@hotmail.co.uk 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 common thing to do). I have avoided including the is_*() functions into this RFC because my main priority is to get this particular feature into PHP 7.0 before feature freeze. Provided I have some free time over the next week, I'll write up another RFC + patch to cover the is_*() functions. Thanks,Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] [FINAL DISCUSSION] Script only include/require
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. Those who are not involved, this is the time to check this RFC. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Proposing [constructive] solutions (was: I quit)
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 http://openmrs.org/help would work here. Some kind of point of contact for newcomers (kind frightening to open a thread for the first time). I been hacking around and doing some things. https://github.com/pasindud/sing-php https://github.com/pasindud/sing-php- a localized php syntax (kind of esoteric languages for fun) https://github.com/pasindud/php-extension-st-snippets - Sublime Text Snippets for PHP internals. ( more to do ) I would like to pitch and help, great if someone can point me in the right direction. (not sure whether this is the right list to post in) +1 On Mon, Feb 16, 2015 at 9:01 PM, François Laupretre franc...@php.net wrote: De : Rowan Collins [mailto:rowan.coll...@gmail.com] Saying that's enough isn't even a productive comment. Enough what? What is it you are asking to happen next? Maybe an initiative to write an RFC about the rules we should follow when writing to the list. People who agree could show their support by a vote. The vote would never end and would just mean 'I agree and will try to follow these rules'. It probably already exists somewhere but refreshing it wouldn't be useless. It's purely symbolic but, once people explicitly show strong support, it becomes an opposable reference. - There is a lack of expertise at the core level of the code, so collaboration on each feature is low. RFCs tend to have a single sponsor, who has to see the whole process through to the end. - One thing we can encourage, while indirect in this case, is writing more comments in code. With PHP 7, Sara's book is almost unusable and nobody will write another one soon. 'UPGRADING' and friends are fine but far from sufficient, especially for newcomers. The only solution I imagine is adding comments in the code. I know it is annoying when you don't have much time, but comments can be improved at any time. They can be written by the feature author, but also by other people, who needed a (too) long time to understand a feature, and write explanations to help followers. As an example, I spent some time understanding the multi-level architecture of str_[i]replace functions and added a lot of comments along with the patch I will propose. Actually, everywhere you spend time understanding what's going on, more comments are needed. That's really important because, today, the code contains almost no comments except function prototypes. That’s ant work and I am far from perfect about comments in my own code, but it can make a difference, especially making the project more attractive for newcomers (and we *need* new blood). - We also can encourage co-authoring RFCs. People are used to work alone but it can change if there's a will. We can also find a set of skilled volunteers agreeing to give their opinion on RFCs before they're announced on the list. That's just an opinion but it can avoid the discussion going nowhere from the beginning. - The leadership of the language is left to consensus, so that when consensus cannot be reached, someone has to take on the role of mediator / chairman / leader for the feature, and try to push through a compromise. I have no democratic solution for this. In the PHP spirit, as Zeev explained, if the RFC process doesn't bring a consensus before the vote, the discussion should stop and the RFC should be modified. Trying to push it to a 2/3 approval while people are fighting is counter-productive. In this regard, IMO (and I told her), Andrea should have withdrawn her RFC much sooner. It would have allowed to take more time for building the next one, and start a new discussion in a more constructive atmosphere. Upcoming feature freeze was probably the reason but the result is that we need to restart everything from scratch in a bitter atmosphere. - The RFC process traditionally has only one voting phase, with a Proof-Of-Concept patch completed, and voters expecting few implementation details to change. So a lot of time has to be committed to the details of a feature which might be outright rejected. It might be more efficient if the principle of a change, details such as syntax, and final implementation, could be considered separate phases. That's the tradition but I think it is quite open for improvements. While we are traditionally using one final vote with multiple options, nothing refrains anyone to organize informative pre-votes during discussion to test the popularity of a feature before he starts writing code, clearly stating that it is not the final vote. This would allow a better information from the community to the RFC author. The interest of such running pre-votes is that they can contain many
[PHP-DEV] [RFC] Make empty() a Variadic
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 the is_*() functions into this RFC because my main priority is to get this particular feature into PHP 7.0 before feature freeze. Provided I have some free time over the next week, I'll write up another RFC + patch to cover the is_*() functions. Thanks,Tom
Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 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, numeric We should have reserved these. IMHO. Yes, it breaks. However, sooner is better. People don't just use PHP7. We may try to promote these changes now. We still have time. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net Resource is used quite often: https://github.com/search?l=phpq=class+Resourceref=searchresultstype=Codeutf8=%E2%9C%93 Unfortunately, GitHub doesn't allow a search for class Resource for better results. Google knows about 600 occurrences: https://www.google.de/?#q=site:github.com+%22class+resource%22+php One more popular example usage: https://github.com/phacility/phabricator/blob/master/externals/balanced-php/src/Balanced/Resource.php Just to throw some numbers in. Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 and it's valid. My point is about not to implement exceptions at all. If exceptions are not intended to be caught, they don't need to be thrown (even if the context is different). If exceptions are not thrown and not caught, we can use error in dev and some easing severity (warning, zero cost nothing) in prod. Freely adapted from Murphy: If assertion exception can be catched, it will be even in production. Assertion is only for development and testing. We need errors or exceptions during development and testing, but not in production. Therefore, errors/exception should not be catched by code in general. Isn't assertion nature? I don't insist not to enable assertion in production environment. There might be software that needs extreme reliability and stability. For these softwares, it makes sense to enable assertions and catch errors/exceptions to do some cleanups. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Reviving scalar type hints
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 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 makes me very sad, as whether the strict option is there or not I'd *really* love to see scalar hints in PHP 7 to complement return type hinting. Timing just won't work while being fair with alternative proposals. I do not think it is unfair to push it now. In contrary. I've said since I re-opened the proposal that I'm comfortable with it not targeting 7.0... Unless we're willing to push feature freeze by 2-3 weeks for it, it just doesn't make sense to target 7 with people working on an alternate proposal (since by definition they couldn't target 7). 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 is too late. Let face it, some features (like your RFC) will never make it post 7.0. We have to be realistic about how things work now. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 solution, we can start reserve names for the interim period if it is still needed. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] In Operator
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']) { ... }
That would always be false, because $_GET is always strings. To make that
work I'd need to first cast all of the elements in that array to ints...
which I'm not actually sure how to do cleanly.
You need casting anyway if comparing raw GET/POST directly to any
integer as a decision point on whether to use the raw value, i.e. it's
unvalidated otherwise and could have been 1234script[...].
Yes, I'm abusing your intentionally very simple example. There are
other cases away from user input where looser comparisons wouldn't
have the same potential issues with non-permanent type juggling. I
would be a huge fan of having it be strict since the above, while
clearly a simple example, has been problematic in the past for
validation routines and, as a security guy, I'm obsessed with that ;).
Also, on toe-dipping into strict typing, I think your opinion may be
slightly overweight towards that topic given recent RFC history - we
already have === as our toe in the water.
I'd much rather we tighten up the rules around implicit casts generally, as
discussed elsewhere, and then allow those loose but not as loose as we have
now rules here.
I could work with that perhaps. RFCs of this type are in a bit of a
bind while we wait for scalar typehints/potential casting rules to be
finalized in some form. It also appears unlikely that in as the
operator name will pass muster if the context sensitive lexer RFC does
not pass, i.e. would break uses of in() as a method name.
Niklas, any chance you have considered a Plan B for the operator
naming? Mostly curious if these is already some alternative outside of
the field of langs I'm familiar with that might be acceptable.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 voting on additional types not included in his RFC: resource, object, scalar, mixed, numeric We should have reserved these. IMHO. Yes, it breaks. However, sooner is better. People don't just use PHP7. We may try to promote these changes now. We still have time. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
RE: [PHP-DEV] Reviving scalar type hints
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 dual-mode mechanism, compared to the ruleset I am intending to propose (currently in draft): https://wiki.php.net/rfc/zpp-conversion-rules ? Actually, using such ruleset, I guess you could infer less, but the difference wouldn't be so important. Only 3 conversions still use value, from which one can be made type-dependent-only if requested during discussion (float to int proposed as lossless-only). Every type except int, float, and string are also proposed as 100% strict. I'm not sure we can go much further with a single-mode approach, but I'll appreciate your opinion. Of course, anyone else is welcome too. Regards François -Message d'origine- De : Anthony Ferrara [mailto:ircmax...@gmail.com] Envoyé : vendredi 20 février 2015 02:58 À : Larry Garfield Cc : internals@lists.php.net Objet : Re: [PHP-DEV] Reviving scalar type hints Larry, Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. So that means one less branch (no guard) per argument per function call. In addition, native calls can be used in a lot of cases, which means the compiled code doesn't even need to know about a zval (significant memory and access reduction). This has potential to be significant. Not to mention the other optimizations that are possible. However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 more than a hack to have a flawed design approved by all means.
- Storing builtin types in the root namespace would cause exactly the same
problem of sharing a naming space with user-defined names.
- and probably the most important one: the implementation is based upon the ZPP
layer, which allows internal and userland type hinting to follow exactly the
same logic.
About namespaces : no type hinting feature is currently planned at the
namespace level, except the usual class resolution when a class name is used as
hint. Some may exist in the future as there will probably be more links between
built-in types and classes, such as specializing and combining builtin types
using a userland class or exposing builtin-types as classes.
Regards
François
-Message d'origine-
De : Dennis Birkholz [mailto:den...@birkholz.biz]
Envoyé : vendredi 20 février 2015 22:22
À : internals@lists.php.net
Objet : Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 not a question of namespace resolution. Built-in type hints and
namespaces have nothing in common.
I do not know how the actual implementation works, but I assume there is
a symbol table for each namespace that contains a list of
class/trait/interface names for that namespace. Why not enhance this
mechanism to contain all type information for each namespace? Simple
types go into that symbol table, type aliases, type defs/enum types (if
such a thing gets implemented), union types, etc. In addition, if the
current namespace symbol table does not contain an entry (and the
autoloader fails), the root namespace is tested for a name.
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 ?
The class definition would give an error, as resource already exists
in the topmost namespace.
namespace test {
Class resource { ... }
function foo(resource $arg, ...)
}
function bar(resource $arg, ...)
foo uses the class test\resource, bar uses the resource type from the
root namespace.
Maybe PHP works completely different internally and this is not
feasible. But reserving some names from being valid as a class name
sounds like a hack, I would prefer a clean and generic solution.
Thanks
Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Deadline for 7.0 (was: Reviving scalar type hints)
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 is too late. Let face it, some features (like your RFC) will never make it post 7.0. We have to be realistic about how things work now. Agreed. It was announced 4 months from November but in such case, it is much too short. On the other side, the vote for the 7.0 timeline got 34 yes and 2 no. So, I assume people knew what they were doing. The RFC heavily insists on the need to keep the timeline as short as possible, so there probably was a reason, although it is not clearly explained. My main concern is not about not being able to have my RFCs approved for the date, at least not directly. My concern is about the new features we'll announce. That's a major version. Everyone will talk about it. We have a communication window that won't open again before years. After the PHP 6 adventure, we'd better not fail this one ! So, what's the killer feature ? What do we put forward ? What do we base our communication on ? What do we want papers to talk about ? phpng ? That's great work, but low level, not much to sell except boring statistics ;), I may be wrong but, IMO, not much to explain to the average user: Look, that's faster, do you want to know why ? Absolutely not, thank you. People want *features*, and we don't have so many to sell. Looking at the list of RFCs for 7.0, most are minor from a user's pov, or too low-level to communicate on. Putting that in parallel with the recent activity on the list saddens me a bit, because several projects are coming, that can make a difference : STH (any version), of course, but also DbC, annotations, expectations. Named parameters would be great too if Nikita is OK. Parser extension API is a little low level for the average user but very interesting too. This is all recent, as Pierre explained, because most of these people were busy testing the core one month ago. Now, if we stick to March 15, most of this won't go to 7.0 and some can even be lost forever. I hear some saying that, if it does not go to 7.0, it will be for 7.1. I disagree : a good part of this will be killed by BC breaks and the communication window will be closed by 7.1. 'PHP 7 features' will be announced everywhere. Definitely not the same for a minor version. So, it's time to make a decision. My opinion is that, if we want to build a good feature list, we need more than 2-3 weeks. I would say roughly another 4 month : not too short, not too long. Thoughts ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 wrong. my 2 cents ...exceptions are not used by default... Can't find this point in RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
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 for consistency: C:\dev\php-srcphp -r var_dump((real) 42, is_real(13.37)); float(42) bool(true) How do others else feel about this? I am undecided at the moment. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
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 deprecated / removed sooner than later instead of kept around. It's minor, i know, but consistency wins above a quick find/replace above all. With lesser roads to the destination (rome), the easier the route to follow ;) Atleast have it on a roadmap somewhere instead of keeping it around and in every discussion with regards to reserved keywords, typehints, return types etc etc Thanks and keep up the good work ! (can't wait to see what PHP7.0 will actually bring to the table) Thnx, Robin Speekenbrink 2015-02-20 17:11 GMT+01:00 Andrey Andreev n...@devilix.net: 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 of action, it is out of scope of this RFC. I personally think that reserving it is a good way to discourage its use: simply reserve it and then don't use it for anything. If we decide not to use the aliases if we have scalar types and the aliases are reserved this would prevent users from making custom types from the aliases. In my opinion this a Good Thing. Well, I meant to deprecate is_double(), is_real() and the corresponding explicit casts. I might be missing other places when they are used, not sure, but the point would be to stop using these names for scalar types at all, so that everybody can freely use them for class/trait/interface names ... I don't think anybody would do that only for pseudo-scalar hinting objects. So, while yes - that's outside of this RFC's scope, reserving them as keywords would be the opposite of what I had in mind. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 there's also an objective issue. There's a serious question mark whether the type of hint - strict, coercive of otherwise can have any sort of implications on one's ability to conduct static analysis, JIT or AOT (I'm bringing those up again since they're closely related in terms of what you can or cannot infer). Now, I'll contend that even though I don't think we are, perhaps we're missing something. But at the very least it should be clear to the list there's serious doubt on whether there's any extra value there even if they do seem static analysis critical. If there is, it's likely to be very, very limited in scope. That's not saying you should want to use statically typed for everything. And nor would I support PHP moving to pure statically typed (which is why the proposal I'm backing doesn't). We're on the same page here. But the kinds of static analysis benefits you seem to believe we can get from strict type hints would require that - strong typing, variable declarations, perhaps changes to casting rules - not just around that narrow interface between callers and callees. Thankfully that's not on the table. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.6.6 is available
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 regression at one point). Well, we allowed multiline headers but it is an extremely exotic feature which is now dropped from the HTTP/1.1 standard, and also it causes security issues with IE users since IE never supported that feature properly. So given that I've decided to remove it even though strictly speaking it is a BC break (same goes for the HTTP standard). duh, should have checked the commit first. so since php 5.1.2 we were disallowing multiple headers to be set in the same header() call (as in header(Foo: bar\r\nBaz: foo);) but we still kept the ability to have multiline headers (as in header(Foo: bar\r\n baz);) which still caused some problem for some browser, so we had a discussion about removing multiline header support altogether: http://comments.gmane.org/gmane.comp.php.devel/88039 so Florian is correct that this is a BC break (albeit in a less known/discouraged feature which was causing security problems over the years).
Re: [PHP-DEV] [VOTE] Expectations
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 valid reasons to hold off progress. zend.assertions: Having a more general debug setting might be a good idea, but is outside of the scope of this RFC. assert.exceptions: Delay isn't necessary, exceptions are not used by default, and there is plenty of time for Engine Exceptions to make necessary changes. Cheers Joe On Fri, Feb 20, 2015 at 2:55 PM, Crypto Compress cryptocompr...@googlemail.com wrote: 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. 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 intended to be caught, they don't need to be thrown (even if the context is different). If exceptions are not thrown and not caught, we can use error in dev and some easing severity (warning, zero cost nothing) in prod. Freely adapted from Murphy: If assertion exception can be catched, it will be even in production. The point behind AssertionException is that a) It will leave the scope where with the failed assertion immediately. A warning would continue running the code, even though some precondition is violated, which doesn't make sense. Assumed context is wrong here. - exception in development: error - no exception in production: warning, zero cost nothing Rephrased: A zero-cost non-existing exception would continue running the code, ... In a previous email you brought up the point if or not derive AssertionEx from Exception. I argue that all child exception MUST BE derived from Exception. Any exception to this is not an Exception. (my english is too limited to explain this, sorry) b) It can still be gracefully handled (unlike a fatal error). E.g. the unit testing framework can catch it, so you can continue running all your tests even if one causes an assertion failure. Unit test frameworks do this already. No change here. When Joe says not intended to be caught this is referring to normal code. Catching them at the top-level still makes sense, e.g. for the unit testing case mentioned or even just to print a nice error message with extra information. Using an exception instead of a fatal error also means that things like finally will still run, so your code can still release locks etc even if an assertion failure occurred. In production this will never happen. We go round in circles here. I am aware of you preference on exceptions everywhere. Nikita
Re: [PHP-DEV] [VOTE] Expectations
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 questions in this thread. I also do not like other things. These don't seem like valid reasons to hold off progress. zend.assertions: Having a more general debug setting might be a good idea, but is outside of the scope of this RFC. 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. assert.exceptions: Delay isn't necessary, exceptions are not used by default, and there is plenty of time for Engine Exceptions to make necessary changes. So basically what you say is that this RFC, relying on things we should clarify and define clearly so it will be consistent across the engine and language, are not relevant to this RFC? I totally disagree and hence my point that this RFC needs more (public) discussions and things that are prerequisites for this RFC should be designed, discussed and implemented before this RFC. I will certainly be the only one voting no at this stage, or maybe not even voting because I simply feel like you discussed that already no matter where and came to this RFC and say take it or leave it. I am not a fan of this approach or we can rename Request For Comments to Request to Accept as any kind of comments or feedback is simply not taken into accounts. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] In Operator
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, $needle) !== false. These functions have a inconsistent parameter order, so it's hard to remember which is the right one for each. The in operator makes these checks way more readable. Additionally, it also works for Traversable. https://wiki.php.net/rfc/in_operator | It uses strict comparison (===) for array values / instances of | Traversable This might be nice but is inconsistent with other parts of the language like switch statements. I think inconsistency is worse than this inconvenience. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
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 of action, it is out of scope of this RFC. I personally think that reserving it is a good way to discourage its use: simply reserve it and then don't use it for anything. If we decide not to use the aliases if we have scalar types and the aliases are reserved this would prevent users from making custom types from the aliases. In my opinion this a Good Thing. Well, I meant to deprecate is_double(), is_real() and the corresponding explicit casts. I might be missing other places when they are used, not sure, but the point would be to stop using these names for scalar types at all, so that everybody can freely use them for class/trait/interface names ... I don't think anybody would do that only for pseudo-scalar hinting objects. So, while yes - that's outside of this RFC's scope, reserving them as keywords would be the opposite of what I had in mind. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 you say is that this RFC, relying on things we should clarify and define clearly so it will be consistent across the engine and language, are not relevant to this RFC? I totally disagree and hence my point that this RFC needs more (public) discussions and things that are prerequisites for this RFC should be designed, discussed and implemented before this RFC. I'm saying that this isn't a subject for this RFC, deciding if we're going to have multiple exception trees is simply not in scope. I will certainly be the only one voting no at this stage, or maybe not even voting because I simply feel like you discussed that already no matter where and came to this RFC and say take it or leave it. I am not a fan of this approach or we can rename Request For Comments to Request to Accept as any kind of comments or feedback is simply not taken into accounts. I'm sorry that you don't remember the discussion, but it did happen, the RFC has been in (more or less) it's current form for more than a year. The current form *is the result of discussion*. Please stop saying it hasn't been discussed, it has, a lot. Cheers Joe On Fri, Feb 20, 2015 at 3:48 PM, Crypto Compress cryptocompr...@googlemail.com wrote: 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 wrong. my 2 cents ...exceptions are not used by default... Can't find this point in RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
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 more controversial than what I have proposed. Remove 'double' (avoid this alias if we decide to encourage 'float' everywhere) Not sure we'll use Boolean and integer but reserve also. Hope 'null', 'true', and 'false' can technically be used as type hints. If not, bad news, especially for null. Love 'int|false' as return type ! This is out of scope for this RFC, but if this RFC passes they would be reserved which means this *could* be done without BC breaks in the future. I'd rather not reserve 'resource'. Such a hint may be useful in the short term, but there already are plans to turn the current resources into objects, and with the rise of REST lately it is also an obvious base class/interface/trait name. 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 of action, it is out of scope of this RFC. I personally think that reserving it is a good way to discourage its use: simply reserve it and then don't use it for anything. If we decide not to use the aliases if we have scalar types and the aliases are reserved this would prevent users from making custom types from the aliases. In my opinion this a Good Thing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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, this is a subjective question that others might answer differently.
But there's also an objective issue. There's a serious question mark whether
the type of hint - strict, coercive of otherwise can have any sort of
implications on one's ability to conduct static analysis, JIT or AOT (I'm
bringing those up again since they're closely related in terms of what you
can or cannot infer).
Now, I'll contend that even though I don't think we are, perhaps we're
missing something. But at the very least it should be clear to the list
there's serious doubt on whether there's any extra value there even if they
do seem static analysis critical. If there is, it's likely to be very, very
limited in scope.
Let's simply agree to disagree here :-)
That's not saying you should want to use statically typed for
everything. And nor would I support PHP moving to pure statically
typed (which is why the proposal I'm backing doesn't).
We're on the same page here. But the kinds of static analysis benefits you
seem to believe we can get from strict type hints would require that - strong
typing, variable declarations, perhaps changes to casting rules - not just
around that narrow interface between callers and callees. Thankfully that's
not on the table.
That's also not necessary in most cases. You can infer a lot about the
types of variables just having arguments declared. In most cases, you
can infer enough for static analysis to work. In the cases you can't,
that's actually a valid result of the analysis because you may have
undefined behavior. Example:
function foo(string $a): int {
return $a + 1;
}
You can't infer the type of $a+1 because the conversion of $a-numeric
that happens is unstable from a type perspective. But PHP's type
changes are predictable enough where the majority of sane cases are
predictable.
Both Swift and Go behave like this. Where you only *need* explicit
declarations on the arguments, the rest can be inferred. And where it
can't infer, it raises a type error.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Make empty() a Variadic
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 common thing to do). I have avoided including the is_*() functions into this RFC because my main priority is to get this particular feature into PHP 7.0 before feature freeze. Provided I have some free time over the next week, I'll write up another RFC + patch to cover the is_*() functions. From the RFC: This behaviour seems to be the most prevalent usage of multiple empty checks in a condition, therefore benefitting the most end users. Here I disagree. I would have assumed from the start that empty() would only return true if *all* of the entries are empty, i.e. AND things together. If we enable variable arity then it will join the group of function where no user sanely can remember if in_array/etc. take the needle/haystack first or second argument. I.e. whether it will OR or AND all arguments. From the RFC: Also, it will make empty() more inline with the not-too-disimillar isset(), which is good for the Principle of Least Astonishment (mainly aimed at neophyte developers). From http://php.net/manual/en/function.isset.php : If multiple parameters are supplied then isset() will return TRUE only if all of the parameters are set. Evaluation goes from left to right and stops as soon as an unset variable is encountered. But this is an AND: ... if all ... are set: isset($a,$b) behaves like isset($a) isset($b) IMHO this absolutely violates your POLA because as I said this is also how I would assume empty() with variable arguments would work: Only return true if all are true. My personal opinion is that any attempt to change this is ill-fated because people will no be able to memoize the exact usage of it because it would mean different things to different people and would just add more confusion. -1 on the proposed change. - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 ? Regards -Message d'origine- De : Dennis Birkholz [mailto:den...@birkholz.biz] Envoyé : samedi 21 février 2015 07:06 À : internals@lists.php.net Objet : Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7 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 type hints RFC has passed so far, we could also define it in a clean way and just put the scalar types into \, then we can not have the conflicting classes there and have to use function foo(\int $c) instead of function foo(int $c) which is a lot better that switching type hints for classes to something like function bar (object(my\namespaced\class) $a). - I think it would be slower, and we need speed, but I agree, I did no test I don't know this. - no pre-defined namespace exists to handle this There is \ - Reverting to the root namespace makes it twice slower. The case of functions is nothing more than a hack to have a flawed design approved by all means. Also you could just use \int, \string; on top of the file, than function foo(int $c) is ok. In total, I think that is the BC-break safe way to go, it will keep the door wide open for union types, etc. without the worry of BC breaks. We could leave out all the hacky stuff here. We could even use \PHP as the namespace to go. - Storing builtin types in the root namespace would cause exactly the same problem of sharing a naming space with user-defined names. No, because you can just move you classes into a namespace and add some use statements to the top of the consumer files (with different namespaces in use). With the current proposals, you have to invent new names for you classes. - and probably the most important one: the implementation is based upon the ZPP layer, which allows internal and userland type hinting to follow exactly the same logic. I consider this a detail that should not prevent a clean language design. It may mean more work in the short time but I think this will greatly increase the adoption rate if we can eliminate the BC break here. About namespaces : no type hinting feature is currently planned at the namespace level, except the usual class resolution when a class name is used as hint. Some may exist in the future as there will probably be more links between built-in types and classes, such as specializing and combining builtin types using a userland class or exposing builtin-types as classes. Thanks Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 21:46:45 So no, it has not given what is presented. Anyway, I see no point arguing about the lack of discussions as you obviously won't change your mind nor go back to discussion for this RFC. Pointless and waste of time. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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,
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 there's also an objective issue. There's a serious question mark
whether the type of hint - strict, coercive of otherwise can have any sort
of implications on one's ability to conduct static analysis, JIT or AOT
(I'm bringing those up again since they're closely related in terms of what
you can or cannot infer).
Now, I'll contend that even though I don't think we are, perhaps we're
missing something. But at the very least it should be clear to the list
there's serious doubt on whether there's any extra value there even if they
do seem static analysis critical. If there is, it's likely to be very,
very limited in scope.
Let's simply agree to disagree here :-)
That's not saying you should want to use statically typed for
everything. And nor would I support PHP moving to pure statically
typed (which is why the proposal I'm backing doesn't).
We're on the same page here. But the kinds of static analysis benefits you
seem to believe we can get from strict type hints would require that -
strong typing, variable declarations, perhaps changes to casting rules -
not just around that narrow interface between callers and callees.
Thankfully that's not on the table.
That's also not necessary in most cases. You can infer a lot about the
types of variables just having arguments declared. In most cases, you
can infer enough for static analysis to work. In the cases you can't,
that's actually a valid result of the analysis because you may have
undefined behavior. Example:
function foo(string $a): int {
return $a + 1;
}
You can't infer the type of $a+1 because the conversion of $a-numeric
that happens is unstable from a type perspective. But PHP's type
changes are predictable enough where the majority of sane cases are
predictable.
Both Swift and Go behave like this. Where you only *need* explicit
declarations on the arguments, the rest can be inferred. And where it
can't infer, it raises a type error.
Anthony
OK, performance is out then. :-)
Anthony, please explain this to me next:
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 whatever static analysis tools you feel are appropriate.
In what circumstances would I as a Drupal core developer (a few hundred
thousand lines of code, need high degree of correctness, 2500 developers),
contrib developer (a few thousand lines of code, medium correctness guarantee,
3 developers), or a client consultant (a few hundred lines of custom one-off
code, 1 developer) want to enable strict mode?
Using strict typing would out more work on me. How much varies with the part of
the application. (Closer to IO, more work.) Having it in the language means I
will run into it sometime, even if not in code I originate. If potential
performance is not a factor, then what is my carrot? What day to day benefit
would I get from doing so other than pedantry?[1] You can infer things
doesn't make it clear what the day to day impact is for me. Concrete examples,
please.
If it would only matter to the Facebook's of the world, well, they've got HACK
already. How would this practically help Drupal, Symfony, Zend Framework,
OwnCloud, Doctrine, phpMyAdmin, etc?
[1] I'm hardly one to object to pedantry, of course, but that in itself is not
enough to push 2500 developers to use it.
[PHP-DEV] Re: [RFC][Discussion] In Operator
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 Sensitive Lexer have to be voted first. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 to be focused on one thing. This is another subject. So basically what you say is that this RFC, relying on things we should clarify and define clearly so it will be consistent across the engine and language, are not relevant to this RFC? I totally disagree and hence my point that this RFC needs more (public) discussions and things that are prerequisites for this RFC should be designed, discussed and implemented before this RFC. I'm saying that this isn't a subject for this RFC, deciding if we're going to have multiple exception trees is simply not in scope. Why I use the word prerequisite and not part of this RFC. I will certainly be the only one voting no at this stage, or maybe not even voting because I simply feel like you discussed that already no matter where and came to this RFC and say take it or leave it. I am not a fan of this approach or we can rename Request For Comments to Request to Accept as any kind of comments or feedback is simply not taken into accounts. I'm sorry that you don't remember the discussion, but it did happen, the RFC has been in (more or less) it's current form for more than a year. The current form *is the result of discussion*. Please stop saying it hasn't been discussed, it has, a lot. Some stuff covered by this RFC have part of a bigger discussions about many different things. Did we have a [RFC][Discuss] thread to actually discuss this exact RFC? No, we did not. And it is cruelly needed. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Nightmares on type hints, annotations, and aop...
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 too negative : I'd love to see poetic intent more often, and considering type hints as contracts is a powerful way to explore the concept, that very few suggested. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PDO_DBLIB type handling
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 together an RFC? My main question would be whether people would rather have this be the default/only behavior, or whether it should be opted into via PDO::ATTR_STRINGIFY_FETCHES. Thanks, Adam
Re: [PHP-DEV] [VOTE] Expectations
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 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 to be focused on one thing. This is another subject. So basically what you say is that this RFC, relying on things we should clarify and define clearly so it will be consistent across the engine and language, are not relevant to this RFC? I totally disagree and hence my point that this RFC needs more (public) discussions and things that are prerequisites for this RFC should be designed, discussed and implemented before this RFC. I'm saying that this isn't a subject for this RFC, deciding if we're going to have multiple exception trees is simply not in scope. Why I use the word prerequisite and not part of this RFC. I will certainly be the only one voting no at this stage, or maybe not even voting because I simply feel like you discussed that already no matter where and came to this RFC and say take it or leave it. I am not a fan of this approach or we can rename Request For Comments to Request to Accept as any kind of comments or feedback is simply not taken into accounts. I'm sorry that you don't remember the discussion, but it did happen, the RFC has been in (more or less) it's current form for more than a year. The current form *is the result of discussion*. Please stop saying it hasn't been discussed, it has, a lot. Some stuff covered by this RFC have part of a bigger discussions about many different things. Did we have a [RFC][Discuss] thread to actually discuss this exact RFC? No, we did not. And it is cruelly needed. Cheers, -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] [RFC][Discussion] In Operator
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. Currently, we have to usein_array($needle, $haystack, true) or strpos($haystack, $needle) !== false. These functions have a inconsistent parameter order, so it's hard to remember which is the right one for each. The in operator makes these checks way more readable. Additionally, it also works for Traversable. https://wiki.php.net/rfc/in_operator | It uses strict comparison (===) for array values / instances of | Traversable This might be nice but is inconsistent with other parts of the language like switch statements. I think inconsistency is worse than this inconvenience. I would be in favour of strict comparison. Being consistent with in_array() sounds great, but the loose comparison makes it difficult to use in certain use cases. A common usage would be a contains/in validator, for example, where loose comparisons can pass unwanted values depending on how it's written. I'm not fumbling in the dark, it has created a security issue in at least two frameworks. Since it's a new operator in isolation, tightening such rules would be welcome. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 whatever static analysis tools you feel are appropriate. In what circumstances would I as a Drupal core developer (a few hundred thousand lines of code, need high degree of correctness, 2500 developers), contrib developer (a few thousand lines of code, medium correctness guarantee, 3 developers), or a client consultant (a few hundred lines of custom one-off code, 1 developer) want to enable strict mode? So, in what circumstances? Well, I think there are a few cases we need to talk about: In legacy systems (Wordpress, existing versions, etc): In these cases, strict mode would likely go in only extremely sensitive corners. So areas dealing with cryptography, random number generation, session security, etc. And it would go in slowly, as someone revamps it. Not all at once. Just like unit testing, scalar types would be refactored in very slowly, in the critical corners of legacy systems. It's unlikely that more than 1-2% of the entire system would ever become typed. In non-legacy systems it will likely come down to developer experience coupled with benefits of the tooling to the problem. A few hundred LOC script would likely never enable strict mode, and would be just fine because of it (you can mentally keep a few hundred LOC in your head at one time). The larger the project, the more the contributors, the more the benefits to using strict mode. That's not to say that large projects would immediately go full strict. It's just pointing out that the tradeoffs would need to be weighed by the authors. The proposals that Andrea and now I have put forward give the choice to the authors, and give the power to them. If they are not convinced to go strict, then they won't. And there's nothing wrong with that. But those who do want to go strict can. The real key that you should be thinking about is when errors are detected. The stricter the type system, the earlier the errors can be detected. In a lot of cases, a strict-mode type system can detect the vast majority (if not all) of type-related errors at compile time. That's a big benefit for large projects with many moving parts. Using strict typing would out more work on me. How much varies with the part of the application. (Closer to IO, more work.) Having it in the language means I will run into it sometime, even if not in code I originate. If potential performance is not a factor, then what is my carrot? What day to day benefit would I get from doing so other than pedantry?[1] You can infer things doesn't make it clear what the day to day impact is for me. Concrete examples, please. It's more work on you when you write a single line of code. It's less work when you're making a single line change in a 1-million-loc app. It's less work because the type system can verify that the change won't cause type errors when running (where even unit tests won't give you the same level of confidence). Beyond that, I'd highly recommend reading this article: http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-before-debating-type-systems If it would only matter to the Facebook's of the world, well, they've got HACK already. How would this practically help Drupal, Symfony, Zend Framework, OwnCloud, Doctrine, phpMyAdmin, etc? Hack hasn't been out to the public for that long of a time, yet look at the buzz it's generating. Look at the frameworks that are popping up with it. Look at the libraries. I think if anything, the appearance of Hack (and its adoption) show that people want static typing, at least to some level... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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.
-Message d'origine-
De : Dennis Birkholz [mailto:den...@birkholz.biz]
Envoyé : vendredi 20 février 2015 20:17
À : internals@lists.php.net
Objet : Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
Am 20.02.2015 um 19:51 schrieb Markus Fischer:
From the RFC:
“resource”
“object”
“scalar”
“mixed”
“numeric”
... prohibits their usage as class, interface and trait names.
This is such a major BC break.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Allow to use argument unpacking at any place in arguments list
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 (array_udiff, array_interect_ukey, etc.) and just feels a bit incomplete... I would like to propose to allow usage of argument unpacking at any place in arguments you are passing. The patch is pretty simple, you look at it here: https://github.com/nikita2206/php-src/compare/master...unpack-mid-argument-list I still haven't tested performance on the real life apps, but all the synthetic benchmarks (incl. deep recursion in order to let call stack go over the cpu cache) show that there's no difference between this patch and master. Callgrind shows that there is a small increase in the number of instructions ran, which is expected but seems as to be negligible. (It's about 0.5% increase for recursion benchmark). I'm not sure if this change requires an RFC because this is a pretty small, advancement of already existing feature that doesn't contain any BC breaks. So I would be happy if this could go forward without it, but if people disagree here I will make an RFC, that's not a problem (although I would need some karma...) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
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 more controversial than what I have proposed. Done https://wiki.php.net/rfc/reserve_even_more_types_in_php_7 -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Deadline for 7.0; was: [RFC][Discussion] In Operator
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 March 15 to be included in 7.0, but that is kind of ambiguous, now you mention it. Thoughts, fellow Internaleers? Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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, numeric -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
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 class/interface/trait names and type hinting keywords, each addition of a new keyword will be a real problem. So, we may reserve keywords in advance but it cannot be more than a workaround. If we don't address the issue now, we'll end up with weird names for type hints, just because appropriate ones are *too appropriate* and potentially taken for existing or future classes, without any way to evaluate the potential BC break, let alone the potential introduction of a third naming space with a future 'typedef' feature ;). We see the case today with 'resource' but that's just the beginning. What about 'mixed', 'scalar', or others I don't imagine yet ? The race to reserving keywords is lost in advance. Another point is that, thinking the reverse way, developers can legitimately ask why they cannot choose 'resource' as a class name, when the reason for this is a design mistake made when the 'array' type hint was introduced, or even before, when class hints were introduced without thinking the mechanism would be necessarily be extended. Just a detail: I respectfully suggest anyone not to waste time to explain that the problem is solved by using lowercase-only keywords, at least not to me ;) So, we need to propose a migration path towards a cleaner syntax. The STH RFC we are writing proposes one, keeping it as smooth as possible because the feature is heavily used. Back to the particular case of 'resource': As the future of resources may be to be converted to objects while keeping the same API, the STH RFC will propose to define the 'resource' type hint as accepting 'IS_RESOURCE|IS_OBJECT', without conversion. Then the user who received it can distinguish with is_resource/is_object() if needed. So, 'resource' and 'resource|object' will be synonyms, while more precise users can use something like 'resource|object(GMP)'. All of these syntaxes will provide full BC when switching from resource to OO. Thought ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
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 awesome, particularly the BC aspects. Nice work. :) 2. For zend.assertions, is it worth defining constants with more meaningful names that can be used in place of the magic values? They're pretty arbitrary as it stands. My vote's not conditional on that — I'm +1 even in its current form — but I wonder if we can make this a little easier for users. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
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 think of deprecating it. While deprecating it might be a good course of action, it is out of scope of this RFC. I personally think that reserving it is a good way to discourage its use: simply reserve it and then don't use it for anything. If we decide not to use the aliases if we have scalar types and the aliases are reserved this would prevent users from making custom types from the aliases. In my opinion this a Good Thing. Well, I meant to deprecate is_double(), is_real() and the corresponding explicit casts. I might be missing other places when they are used, not sure, but the point would be to stop using these names for scalar types at all, so that everybody can freely use them for class/trait/interface names ... I don't think anybody would do that only for pseudo-scalar hinting objects. So, while yes - that's outside of this RFC's scope, reserving them as keywords would be the opposite of what I had in mind. Right, but it is a yes/no list of options. It makes no sense to have competitive RFCs for such a trivial set of choices. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] In Operator
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: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/Expr.php#L443 I don't think changing the language in a way that breaks Doctrine would be feasible. I second this. I didn't immediately reply when I read this restriction regarding methods but it should have been obvious. IMHO this is an absolute no-go; and the contex_sensitive_lexer sounds reasonable but has it's own problematic areas. - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 is in Hack because
in Hack the internal API is largely untyped while your proposal is to
default the entire internal API to strict types in strict mode. Also, in
Hack there is a distinction between the off-line hh_client type-checker
and the runtime.
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 concerned as well
as the runtime, of course, but they are runtime fatals in your proposed RFC.
And if you only go by the runtime and ignore the out-of-band type
checker there are almost no strictness rules applied to the internal API
in Hack.
eg. explode(0, 1000);
Here the hh_client type checker will complain that it is expecting
strings, but the runtime will run it nicely.
So when you say, and as I have heard other people say, that people want
Hack-like strict typing, you have to be a bit careful about what is
meant by that. Even in the cases where the internal API is typed in
Hack, it is still not a runtime fatal if they are called with the wrong
types. Now whether that is a good thing or not is debatable, of course,
my point is simply that if you are going to use Hack adoption as a sign
that people want static typing you should clearly explain that your
approach is quite different from what Hack is doing.
-Rasmus
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 his RFC: resource, object, scalar, mixed, numeric -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 his RFC: resource, object, scalar, mixed, numeric From the RFC: “resource” “object” “scalar” “mixed” “numeric” ... prohibits their usage as class, interface and trait names. This is such a major BC break. - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 should mention that your
proposed RFC goes well beyond the strict typing that is in Hack because
in Hack the internal API is largely untyped while your proposal is to
default the entire internal API to strict types in strict mode. Also, in
Hack there is a distinction between the off-line hh_client type-checker
and the runtime.
This distinction is going away pretty soon. The typechecker is an integral part
of Hack, and you shouldn't be able to ignore its errors. The runtime will soon
consider them fatal errors too. If your code doesn't pass the hh_client
typechecker, then its behavior when run on HHVM is completely undefined.
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 concerned as well
as the runtime, of course, but they are runtime fatals in your proposed RFC.\
And they should be errors in Hack too. The reason they aren't are to ease
transitions from PHP to Hack. I'd expect them to be more strongly typed
eventually.
And if you only go by the runtime and ignore the out-of-band type
checker there are almost no strictness rules applied to the internal API
in Hack.
eg. explode(0, 1000);
Here the hh_client type checker will complain that it is expecting
strings, but the runtime will run it nicely.
So when you say, and as I have heard other people say, that people want
Hack-like strict typing, you have to be a bit careful about what is
meant by that. Even in the cases where the internal API is typed in
Hack, it is still not a runtime fatal if they are called with the wrong
types.
See above -- relying on (or even really thinking about) this distinction is
relying on implementation details which are going to change.
Josh
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 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 the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. May, could, would, all that are totally irrelevant to the debate about type hinting. The speed benefit is not significant. What is significant? Miracle ability of static analyzes for AOT? Please, can we discuss something without snark? And can we get past AOT? It's distracting. I only mentioned it here because I was specifically asked about it. It's not in my RFC. So please, let's get past it. sorry, I shouldn't be too emotional. actually, it's hard to express emotions with may bad English :) I think, you are doing a great job regarding AOT, but I think strict types won't help you a lot. We may discuss it out of the list on next week. if any place, on EFNet, if not the ML must remain the place to discuss things. I think we can agree on that, and we did as far as I can tell :) I didn't agree with you. Probably, I told that performance impact of run-time switch of type hinting semantic is slightly negative and it would be great to fix it if possible. Everyone is saying this shouldn't be voted on based on performance. You, me, Pierre, everyone. Performance is not a stopper for vote, but it doesn't mean it's not important. It is, only not in this context unless the patch changed in such ways that the performance impact becomes relevant. However, as of now, it is not. See Matt's perf results using the usual suspects. Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 your proposed RFC goes well beyond the strict typing that is in Hack because in Hack the internal API is largely untyped while your proposal is to default the entire internal API to strict types in strict mode. Also, in Hack there is a distinction between the off-line hh_client type-checker and the runtime. In addition to what Josh said, I want to make one point here. This distinction is what lead me to push out 0.5 instead of where 0.4 was going. Let me explain: Let's say we don't type internal functions and release 7.1 with the rest of the dual mode type system. Then we're bound to never strictly type internal functions *unless* we introduce a NEW declare setting (declare(strict_types=2) or declare(internal_strict_types=1) or whatever). Which is a bit out there considering people already are testy about this one. So that practically means if we don't allow strict now, we can never tighten it again. However, if we do allow typed now, then we can expand and loosen in the future. If an API is found to be overly strict, it can be loosened (using a union type for example). We have the ability to loosen over time, but not strengthen. That's why I chose to apply the same typing to internal functions as user-land. To not to would be a major mistake IMHO. So that's why I'm moving forward with it. I will add this to discussion points in the RFC. So when you say, and as I have heard other people say, that people want Hack-like strict typing, you have to be a bit careful about what is meant by that. Even in the cases where the internal API is typed in Hack, it is still not a runtime fatal if they are called with the wrong types. Now whether that is a good thing or not is debatable, of course, my point is simply that if you are going to use Hack adoption as a sign that people want static typing you should clearly explain that your approach is quite different from what Hack is doing. It's not quite different. It's subtly different in a few details. But conceptually it's the same. Right, you are doing a gradual transition of an API that wasn't written to be strict. It was written with the assumption that type coercion would take place. If there is a good reason to ease the transition from PHP to Hack there is an even stronger reason to ease the transition from PHP to PHP. And that's why the current proposal has two modes: weak (coercive) and strict (error inducing). The default mode will not change things for anyone. Then they can start adding types, and things will just work. When they are ready, then they can turn on strict mode, one file at a time. Heck, they can run a strict-mode static analyzer on non-strict code to see where potential problems will be (assuming the analyzer has that mode) so they can fix it before committing to strict types in their production app. If that's not the definition of a gradual transition, I'm not sure what else can be done without fundamentally disallowing the ability to strictly type. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
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 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, numeric From the RFC: “resource” “object” “scalar” “mixed” “numeric” ... prohibits their usage as class, interface and trait names. This is such a major BC break. One thing we must do before even considering non required names is to actually check every major apps, frameworks or libraries. If we can avoid a date/datetime clash again, that would be awesome ;) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Deadline for 7.0; was: [RFC][Discussion] In Operator
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, any work on alternate proposal(s) can stop now, as it is too late to compete. Regards François -Message d'origine- De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part de Adam Harvey Envoyé : vendredi 20 février 2015 19:29 À : Niklas Keller Cc : PHP Internals Objet : [PHP-DEV] Deadline for 7.0; was: [RFC][Discussion] In Operator 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 March 15 to be included in 7.0, but that is kind of ambiguous, now you mention it. Thoughts, fellow Internaleers? Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
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 concerned as well
as the runtime, of course, but they are runtime fatals in your proposed RFC.\
And they should be errors in Hack too. The reason they aren't are to ease
transitions from PHP to Hack. I'd expect them to be more strongly typed
eventually.
Right, you are doing a gradual transition of an API that wasn't written
to be strict. It was written with the assumption that type coercion
would take place. If there is a good reason to ease the transition from
PHP to Hack there is an even stronger reason to ease the transition from
PHP to PHP.
-Rasmus
signature.asc
Description: OpenPGP digital signature
