Re: [PHP-DEV] Scalar Type Hints v0.4
On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov nikita@gmail.com wrote: This is exactly what I fear will happen with an arginfo based approach. If even fundamental aspects like the 123 vs 123 (or true vs 1) distinction are suppressed for internal functions, this isn't a strict typing mode, it's just a weak typing mode with slightly different rules. By the way, I realize I wasn't clear in my previous reply to you. I don't mean to dismiss your position and the proposal I put forth was just to get a feel for people's gut reactions to it. Your gut reaction is clearly negative and that will be taken into account when I put up 0.4 of the RFC which may or may not look like this proposal, depending on what others have to say about it. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
On 02/17/2015 04:35 PM, Nikita Popov wrote: I don't buy into Rasmus arguments about internal functions. They concern one particular edge case (int-float coercion) and I doubt they have much relevance if applied to codebases with pervasive use of typehints (where you can be reasonably sure of the types of your variables). Even if, for the sake of argument, we acknowledge the concern as valid we should be discussing that particular case (int-float coercion) rather than dropping the strict typing for internal functions altogether. int-float is actually secondary to 123-int. And while they may be edge-cases there are enough of them that we would be pushing people towards casting by default which should be a last-resort thing, not the first thing you do. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] zend_get_parameters_ex rework
marius adrian popa in php.internals (Fri, 13 Feb 2015 17:56:28 +0200): Thanks patch looks clean and It compiles, i will start testing it Apparently your tests were successful (?): http://git.php.net/?p=php-src.git;a=commitdiff;h=8f968c5416e721983c0efda25ec1f393c8df662a Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_get_parameters_ex rework
On 17/02/15 23:40, Jan Ehrhardt wrote: Thanks patch looks clean and It compiles, i will start testing it Apparently your tests were successful (?): http://git.php.net/?p=php-src.git;a=commitdiff;h=8f968c5416e721983c0efda25ec1f393c8df662a Adrian may have, but I've just wasted 2 hours trying to get the tests to run and all I can get is 'Termsig=11' failures after it creates the test database. But it is running happily on the test site http://php7.lsces.org.uk/wiki/ The thing I would rather be working on is why the PHP5 versions are running more queries on the database then the PHP7 build. The code and database are identical ... only the PHP side is different. But I need a few hours sleep ... -- 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] Scalar Type Hints v0.4
On Tue, Feb 17, 2015 at 4:35 PM, Nikita Popov nikita@gmail.com wrote: I don't like the way this is heading with regards to internal functions. Apart from better inter-compatibility, the primary appeal of Andrea's proposal was that we have the option to make not only userland function calls strict, but internal ones as well. With these modifications this is lost for all practical purposes. (*) Personally, I agree with you. I liked Andrea's proposal a lot, and if we put this back up for vote it probably would pass the 2/3rd majority needed. That said, if we can build a better consensus, we should try to. I don't buy into Rasmus arguments about internal functions. They concern one particular edge case (int-float coercion) and I doubt they have much relevance if applied to codebases with pervasive use of typehints (where you can be reasonably sure of the types of your variables). Even if, for the sake of argument, we acknowledge the concern as valid we should be discussing that particular case (int-float coercion) rather than dropping the strict typing for internal functions altogether. I don't fully buy into it either, particularly if we apply meta-types/unions. I do have to acknowledge his point about encouraging the use of blind casts though. Having a mass of PHP standard library functions suddenly look typed or apply a different set of coercion rules than one is used to is potentially dangerous. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/17/2015 04:35 PM, Nikita Popov wrote: I don't buy into Rasmus arguments about internal functions. They concern one particular edge case (int-float coercion) and I doubt they have much relevance if applied to codebases with pervasive use of typehints (where you can be reasonably sure of the types of your variables). Even if, for the sake of argument, we acknowledge the concern as valid we should be discussing that particular case (int-float coercion) rather than dropping the strict typing for internal functions altogether. int-float is actually secondary to 123-int. And while they may be edge-cases there are enough of them that we would be pushing people towards casting by default which should be a last-resort thing, not the first thing you do. The inability to implicitly cast 123 to int is pretty much the KEY distinction between weak and strict scalar typehints (those pesky value-dependent type checks). If the strict typing mode doesn't offer this, what's the point at all? This is exactly what I fear will happen with an arginfo based approach. If even fundamental aspects like the 123 vs 123 (or true vs 1) distinction are suppressed for internal functions, this isn't a strict typing mode, it's just a weak typing mode with slightly different rules. Nikita
Re: [PHP-DEV] Scalar Type Hints v0.4
On Tue, Feb 17, 2015 at 11:03 PM, Sara Golemon poll...@php.net wrote: Based on conversations here and elsewhere on the internet, I'd like to put forward a rough gameplan for scalar types which I hope addresses most concerns. This is back-of-the-napkin and I'm not asking for a committed yes/no, just pre-rfc set of thoughts. Please don't get hung up on specific names, we can debate those in the coming week(s), I'm only looking for large architectural issues. 1) Introduce scalar types for primitives: bool, int, float, string, resource, object (we already have array) 1a) Introduce meta-types as pre-defined unions (we can add custom unions in a later rfc). A possible list may be as follows (again, we can argue what's in this list separately): * mixed: any type * scalar: (null|bool|int|float|string) * numeric (int|float|numeric-string) * stringish (string or object with __toString()) * boolish (like mixed, but coerces to bool) * etc... 2) Define a way to enable strict mode (we'll be weak by default). 2a) Userspace impact: Strict mode will throw a recoverable error on type mismatch. Weak mode will coerce the type according to conversion rules (See #3), throwing a recoverable error if coercion isn't possible. 2b) Internal impact: The same rules apply to internal functions as userspace functions HOWEVER, we use the types present in ZEND_ARG_INFO structures, not zpp. This has the net effect that every internal function remains effectively untyped unless specifically opted in by means of updating their arg info struct. In weak mode, internal functions coerce according to conversion rules. 3) Tighten up coersion rules for weak mode. i.e. 10 dogs for an int is a violation, but 10 is acceptable. 3a) Userspace impact: We're in a clean slate state, so this is safe from a BC perspective. 3b) Internal impact: Again, behavior remains unchanged unless the ZEND_ARG_INFO struct has been modified to add proper typehints. If typehints have been added, then the more aggressive coersion rules apply during typehint validation. I really want to underline the design expressed in #2b and #3b. zend_parse_parameters()'s types have been removed from the equation in this proposal. This means that, until someone audits a given function and makes the decision to give it a type, it will effectively behave as though always weak, regardless of the caller's flags. This enables us to give the same contractual behavior internally and externally, while still implicitly treating internal functions as a bit special for the purpose of moving forward. I don't like the way this is heading with regards to internal functions. Apart from better inter-compatibility, the primary appeal of Andrea's proposal was that we have the option to make not only userland function calls strict, but internal ones as well. With these modifications this is lost for all practical purposes. (*) I don't buy into Rasmus arguments about internal functions. They concern one particular edge case (int-float coercion) and I doubt they have much relevance if applied to codebases with pervasive use of typehints (where you can be reasonably sure of the types of your variables). Even if, for the sake of argument, we acknowledge the concern as valid we should be discussing that particular case (int-float coercion) rather than dropping the strict typing for internal functions altogether. I'd personally appreciate to just go back to Andrea's proposal with a tweak to fix the declare() issues. Nikita (*) Where practical purposes refers to my assumption that it is very unlikely that we'll add arginfo typehints to the entirety of all bundled functions and the added typehints will not be heavily colored by people trying to shove in weak typing even when strict mode is enabled. For our own good, obviously.
Re: [PHP-DEV] RFC: Expectations
Will update RFC today, thanks for working on it Dmitry :) Cheers Joe On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
Hi, On Tue, Feb 17, 2015 at 2:46 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: Hello, internals! I want to introduce a RFC for providing a userland API for accessing an Abstract Syntax Tree of the source code and to provide userland parser hooks for source code modification: https://wiki.php.net/rfc/parser-extension-api Thanks! The first part, describing https://github.com/nikic/php-ast , looks fine. I see no problems including this extension into PHP-7.0 core distribution. May be even making it required (like ext/reflection). Nikita, what do you think? The second part looks very interesting, however it has some uncovered questions. - API for AST modification - AST validation (someone may insert break node in parameter-list). If you have enough experience, I would suggest you to try writing an external extension that would implement this idea. If you'll need some modification in PHP core (e.g adding callbacks), we may consider including them in PHP-7.0. Thanks. Dmitry.
Re: [PHP-DEV] [RFC] Spaceship operator RFC
go forward. the patch looks fine. Thanks. Dmitry. On Tue, Feb 17, 2015 at 5:47 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! As expected, spaceship operator RFC (https://wiki.php.net/rfc/combined-comparison-operator) passed 43 votes to 11. I'll proceed with merging it soon. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
Updated RFC as requested. I'm just going to wait to hear what Nikita says, especially about optimizing away unqualified calls to assert. I guess this could be viewed as a BC break, it seems like quite a nice break but not sure. Will open voting when we hear from Nikita. Cheers Joe On Wed, Feb 18, 2015 at 6:23 AM, Joe Watkins pthre...@pthreads.org wrote: Will update RFC today, thanks for working on it Dmitry :) Cheers Joe On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] Scalar Type Hints v0.4
On Wed, Feb 18, 2015 at 4:05 AM, Nikita Popov nikita@gmail.com wrote: On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/17/2015 04:35 PM, Nikita Popov wrote: I don't buy into Rasmus arguments about internal functions. They concern one particular edge case (int-float coercion) and I doubt they have much relevance if applied to codebases with pervasive use of typehints (where you can be reasonably sure of the types of your variables). Even if, for the sake of argument, we acknowledge the concern as valid we should be discussing that particular case (int-float coercion) rather than dropping the strict typing for internal functions altogether. int-float is actually secondary to 123-int. And while they may be edge-cases there are enough of them that we would be pushing people towards casting by default which should be a last-resort thing, not the first thing you do. The inability to implicitly cast 123 to int is pretty much the KEY distinction between weak and strict scalar typehints (those pesky value-dependent type checks). If the strict typing mode doesn't offer this, what's the point at all? This is exactly what I fear will happen with an arginfo based approach. If even fundamental aspects like the 123 vs 123 (or true vs 1) distinction are suppressed for internal functions, this isn't a strict typing mode, it's just a weak typing mode with slightly different rules. The difference between true and 1 is even more strict than rules of statically typed languages. Could you write a short list, where the strict types are really useful. In my opinion it's only program verification, but for this case we may enable strict typing by a tool and not in the language definition (we may provide callback in the core). Thanks. Dmitry. Nikita
RE: [PHP-DEV] Scalar Type Hints v0.4
-Original Message- From: Nikita Popov [mailto:nikita@gmail.com] Sent: Wednesday, February 18, 2015 3:06 AM To: Rasmus Lerdorf Cc: Sara Golemon; PHP internals Subject: Re: [PHP-DEV] Scalar Type Hints v0.4 The inability to implicitly cast 123 to int is pretty much the KEY distinction between weak and strict scalar typehints (those pesky value-dependent type checks). If the strict typing mode doesn't offer this, what's the point at all? I am wondering what the point is indeed with preventing 123 to 123. So far, all the concrete use cases people brought up had to do with Apple or 100 dogs, but nobody ever seems to be able to explain why converting 123 to 123 is likely to be a problem real world. Is it really just static analyzers? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 12:51 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
François,
Doctrine relies on nested annotations for a variety of mapping information.
One example:
http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table
Nested annotations are not going to be necessary, because they may be
represented by PHP pseudo-syntax (and/or PHP array syntax)
Doctrine_Join(
ManyToMany($targetEntity=Phonenumber),
JoinTable($name=users_phonenumbers,
$joinColumns=JoinColumn($name=user_id,
$referencedColumnName=id))
inverseJoinColumns=JoinColumn($name=phonenumber_id,
$referencedColumnName=id, $unique=true))
class User {
...
}
$r = new ReflectionClass(User);
$ast = $r-getAnnotation(Doctine_Join);
echo $ast-child[0]-child[0]; // ManyToMany
echo $ast-child[0]-child[1]-child[0]-child[0]; // $targetEntity
or If we provide API similar to SimpleXML
echo $ast[0][0]; // ManyToMany
echo $ast[0][1][0][0]; // $targetEntity
Thanks. Dmitry.
[]s,
On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre franc...@php.net
wrote:
Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko...@gmail.com]
This RFC consists of two parts: parsing API and parser extension API.
Last
one can be rejected, however it can be perfectly connected with
annotation
RFC (if AST will be used as values)
Parser extension API is great. Go on with it. I have a lot of uses in
mind.
As for annotations, general use-case is appreciated. This can be
extended
later in future versions of PHP. Therefore, annotation syntax should
allow
to define key and values. Value can be valid expression (AST? concrete
node? compiled value?) or can recursively contain nested annotations.
Can you give a use case for nested annotations ? I don't see what they
can be needed for.
Thanks
François
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Re: [PHP-DEV] RFC: Expectations
OK thanks. I'm switching to another task :) Thanks. Dmitry. On Wed, Feb 18, 2015 at 10:16 AM, Joe Watkins pthre...@pthreads.org wrote: Updated RFC as requested. I'm just going to wait to hear what Nikita says, especially about optimizing away unqualified calls to assert. I guess this could be viewed as a BC break, it seems like quite a nice break but not sure. Will open voting when we hear from Nikita. Cheers Joe On Wed, Feb 18, 2015 at 6:23 AM, Joe Watkins pthre...@pthreads.org wrote: Will update RFC today, thanks for working on it Dmitry :) Cheers Joe On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] RFC Proposal
On Tue, Feb 17, 2015 at 8:35 PM, Tim Bezhashvyly tim.bezhashv...@gmail.com wrote: Dear PHP internals, this is my first RFC proposal and I am not sure if in this email is supposed to contain all RFC details or just a brief idea .. which is to drop PHP constants in favour of “final immutable variables. I think dropping constant or class constants is a bad idea. Adding immutable variables may make sense, but you should explain use-cases, behavior, syntax, implementation details, etc Thanks. Dmitry. This is basically only a concept but I can also handle its implementation. Please let me know if I have to provide any additional details. Regards, Tim -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Tue, Feb 17, 2015 at 10:13 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: 2015-02-17 19:25 GMT+03:00 Dmitry Stogov dmi...@zend.com: I think yes, However, Alexander thinks differently https://wiki.php.net/rfc/parser-extension-api Of course this is not for 7.0 This RFC consists of two parts: parsing API and parser extension API. Last one can be rejected, however it can be perfectly connected with annotation RFC (if AST will be used as values) firs part may be accepted. The second can't be accepted for 7.0 just because of time limit. (we have feature freeze in a month) As for annotations, general use-case is appreciated. This can be extended later in future versions of PHP. Therefore, annotation syntax should allow to define key and values. Value can be valid expression (AST? concrete node? compiled value?) or can recursively contain nested annotations. Annotaion syntax: key(php-expression-value) php-expression-value is parsed by standard PHP parser into AST. This AST is stored in annotations table at slot key. Constant expressions are evaluated at compile-time and we store only the resulting constant value. Then it's possible to retrieve this AST (or value) using Reflection API. ReflectionMethod-getAnnotations(); ReflectionMethod-hasAnnotation(string $key); ReflectionMethod-getAnnotation(string $key); Then it's possible to traverse AST using some API like https://github.com/nikic/php-ast It also should be possible to evaluate retrieved php-expression-value in some context and reconstruct PHP source for any AST node. Thanks. Dmitry.
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 3:30 AM, Leigh lei...@gmail.com wrote: On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote: We can sigh and tut about this not being the PHP way, but the script author was the one who chose to enter into a tight contract, and the script author, not you, is the one who should have that authority over their own application. I find this view way too extreme. You find giving authority over an application to the application author too extreme? And you find taking authority over a library away from the library author completely acceptable? I'm not suggesting taking authority of the library away from its author, so you question is invalid. If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? This RFC allows you to turn on strict for your library. What it doesn't do is allow you to turn on strict for the calling application. What's yours is yours, what's theirs is theirs. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Hi, On Tue, Feb 17, 2015 at 6:50 PM, Zeev Suraski z...@zend.com wrote: On 17 בפבר׳ 2015, at 18:32, Andrey Andreev n...@devilix.net wrote: Hi, On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote: If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. I agree that it doesn't give everybody what they want - it only gave weak hint supporters *all* that they want. Andrey, I'm a weak typing supporter; I want PHP to never make it easy at the language level to treat 32 and 32 differently; The RFC did exactly that. Yes, I already know that. The difference, and why I keep pointing that out, is that me and many others want strict typing for our own reasons (but still in its entirety instead of as a limited mode) and most of us don't even care if you getting weak typing for your own usage. You can't work towards consensus if your target is to prevent the opposing group of getting what they want. I see both as valuable tools for different jobs and I want to have more tools at my disposal, while you're trying to tell me that I should use only one tool for everything. - The v0.3 RFC didn't give weak hint supporters everything they wanted. QED. Many also objected because strict typing was only opt-in and could never affect the caller's code unless the caller explicitly declares that they want to do that. You're ignoring that and you're twisting it the other way around. It's enough to provide one counter example to disprove an assertion - the assertion that the v0.3 RFC gave everyone what they wanted - and I provided the one I can personally attest to. I certainly didn't claim strict typing supporters got everything they wanted, so I'm not sure why I'm twisting anything. If anything, you're only making the point that the v0.3 RFC doesn't give everyone what they want stronger. Yes, I am making the point stronger. But you implied that most objections were from people who don't want strict typing in PHP at all. And I disagree with that because it's a speculation, which in turn you are using to favor your weak-hints-only case (hence, twisting it in another direction). I think the options we're discussing here take us away from this zero sum game, provides benefits to both schools of thought, and it seems to me as if you were open to it. I'd much rather we invested our energies there! Zeev Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
2015-02-17 16:35 GMT+03:00 Rowan Collins rowan.coll...@gmail.com: I think should is OK for extensions, but not for userland hooks. There needs to be a very firm definition of the right and wrong way to implement these hooks, which can at the very least warn the user when they are slipping into undefined behaviour. Thanks for this point. Added this question to the list of open issues in RFC. My vision is to update a documentation with clear description, why parser extensions should be registered statically without conditions. Parsing process and limitations should be also described in the RFC. 2015-02-17 16:35 GMT+03:00 Rowan Collins rowan.coll...@gmail.com: The other alternative is to go to the other extreme, and have the extensions scoped to a particular file, more like Perl pragmas. Dare I say we could use the declare() syntax that everyone seems to have an irrational hatred of? declare(pragma=Example\DbcParserExtension); Ouch ) Don't like this way at all, because extensions should process all files, even if it's not marked with some hints. What I want to see is PHP analog of Java bytecode compilers, they can transform an original source code into specific tokens and provide custom extensions on top of that. So, I want to choose between php.ini option and explicit methods. Let's see another opinions. Thanks!
[PHP-DEV] [RFC] Spaceship operator RFC
Hi! As expected, spaceship operator RFC (https://wiki.php.net/rfc/combined-comparison-operator) passed 43 votes to 11. I'll proceed with merging it soon. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 15:30, François Laupretre wrote: Returning 'not-zero/empty' as true and 'zero' as false is one of the natural things to use in PHP and I don't think any other language has that flexibility? You didn't read it right. I was talking of conversions *from* bool, not *to* bool. (int - bool) is fine and will be preserved, but I propose to remove (bool - int). You will still return numbers as bool, and non-zero will still be converted to true. Relax :) My current practice up until now has been to use 'return false' when an action failed, but the main return would be a number of records or string of data. So you are now blocking that activity ... I'm reading to right, but you are not thinking all possibilities through. But I think I'm starting to see it broken already with the other changes to the core :( I'm not returning 'IS_FALSE' so I'm probably going to have to change the 'false' to '0' anyway so as to avoid the bool? -- 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] Reviving scalar type hints
On 17/02/15 15:47, Anthony Ferrara wrote: A static analyzer (one of the reasons people want strict) would error there. The reason is that *at compile time* it can't reason about the code well enough to determine if there's an error or not. You're passing a string where you expect an int. Is that going to work? We don't know. So the analyzer would need to throw a warning that the cast is potentially unsafe because it can't guarantee that the runtime won't throw an error. Which means that to remove the warning you'd need to add an explicit cast. This is what I do not get ... I have no idea what string will be provided, so either we get a valid number or we don't. Conversion of the string to a number needs to follow several rules such as thousand divider or decimal point, or perhaps even spelt out numbers. If the input string can't be converted to a number then we need the error message - explicit casting fixed nothing - you can't eliminate the error if the passed string can't be converted so you need an alternate escape route. A generic 'type fault' does not help since you want to return the fault to the inputting source? Static analysis only works if you assume there is no human involvement in the generation of the inputs? Now if you are handling the problem of mistakes in the input prior to the function call you already know that the data is good so why do you need 'strict' at all. You will process the string, decide if you want to tell the client that it must be a whole number, or if it exceeds some limit. That may even be done in javascript in the browser, so what is fed back has already been sanitised. It will come in as a string and you know it is a valid number ... -- 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] Reviving scalar type hints
On 17/02/2015 15:47, Anthony Ferrara wrote: If we want to add a numeric type as a virtual union of int and float, that's one way to solve the concern. If we don't, we could also allow widening primitive conversion (int - float). That wouldn't work well with bigints, but would be fine in other cases. But there are plenty of languages that always require explicit type conversion. So even if we choose that, we're in good company. As far as I understand, allowing int - float would help fix a few of Rasmus' (or was it Benjamin?) concerns about things like sin() requiring floats in strict mode. It would make strict mode a lot more usable with C code as well. +1 on keeping the strictness benefits and remove some of the drawbacks. Having numeric in addition might be nice mostly for return values I guess, but it seems a bit redundant to me if int - float is allowed. As for the straw poll, I also think declare() is the clearest syntax, especially if it's enforced to appear at most once and on top of the file to remove any potential misuses. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new json, push generated file?
Hi Jakub, On Sun, February 15, 2015 21:18, Jakub Zelenka wrote: On Wed, Feb 11, 2015 at 11:56 AM, Jakub Zelenka bu...@php.net wrote: I would like to push the the bison tab files shortly as the majority of people in this thread (including me) are for having them in the repo. The only thing that I would like is to have a specific version in the repo to prevent big diffs for small changes in the source files. For now I would like to have there re2c 0.13.6 (thanks for regenerating it back ;) ) and bison 2.7.1 gen files. I will update Readme at some point as well and add there that info. Hey just a quick update. I bumped the version in the repo for re2c 0.13.7.5 (latest - no changes in generated states ) and bison to 3.0.4 . I updated Readme as well. I have pushed the bison files in http://git.php.net/?p=php-src.git;a=commit;h=911f7b10b1f4c9529bc01580d298a 93a5cd6bbd2 . There is an explanation why the C preprocessor guard macro names are file system dependent. It means why there is YY_PHP_JSON_YY_HOME_JAKUB_PROG_PHP_MASTER_EXT_JSON_JSON_PARSER_TAB_H_INCL UDED . It's due to bison algorithm for creating such name. As I noted the only solution that works for me is using different yacc.c skeleton. I have done it in jsond in https://github.com/bukka/php-jsond/commit/583619d7962fa57bf97dcdac4147d8b 599a42672 where I have optional bison generation which means that I can stick with one bison version and use custom skeleton file. This is however not possible in the core where we allow range of bison versions which doesn't play well with skeletons that are version specific. thanks for pushing. I'm using re2c 0.13.7.5 now for master as well. With bison, it'll be however hard to move from 2.4.1 on Windows (and it's not that critical), but file generated with it seems to work. Anyway, nothing prevents you or anyone to regenerate it and push over, just in case. Most important is that fixes land in the *.re/*.y sources. And one knows who to ping for verifications :) Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Tue, Feb 17, 2015 at 5:06 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 10:15 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@zend.com wrote: hi, During discussion of different ways of implementing Design by Contract we got an idea of using annotations. BTW: annotations are useful by their own and may be used for different purposes. Support for annotations was proposed long time ago: https://wiki.php.net/rfc/annotations https://wiki.php.net/rfc/annotations-in-docblock https://wiki.php.net/rfc/reflection_doccomment_annotations HHVM already implemented similar concept http://docs.hhvm.com/manual/en/hack.attributes.php I made a quick and dirty PoC that shows how we may implement annotations in PHP7 and how powerful they may be : https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2 How about not exposing the AST, and then the userland can pass context to a method $reflection-getAnnotation($name, $context); https://gist.github.com/beberlei/0dc36d4412b8e3454912 That way AST is not exposed to userland. Your example handles just particular use-case. I would like to provide a general solution. Thanks. Dmitry. Could you provide some more info on how you would imagine this to be used for the DbC use case? As far as I see, this would require injecting code into the method body based on the annotations. Does that mean that annotations handlers will get the chance to modify the AST of the method itself during compilation? Or how is this supposed to be realized? In general, it must be possible to plug into compilation process using zend_ast_process() callback and modify function AST, inserting constraints validation in proper places. But for now, I'm thinking only about metadata syntax and representation. I just showed, how it can be used to represent DbC constraints. I don't think we need user-level interface to modify AST. To make sure I got it right: The AST-based annotations are only there to allow handling by PHP extensions (or the engine itself), while evaluated annotations are there for use by userland code? Nikita I think yes, However, Alexander thinks differently https://wiki.php.net/rfc/parser-extension-api Of course this is not for 7.0 Thanks. Dmitry.
Re: [PHP-DEV] Re: Annotations in PHP7
On Tue, Feb 17, 2015 at 4:50 PM, François Laupretre franc...@php.net
wrote:
HI Dmitry,
Question : in which scope do you evaluate the PHP expression ?
We don't evaluate expressions. We just store them. Evaluation and/or
modification is a subject for future development.
Example :
DbC.requires($a 0);
DbC.ensures(__RETURN__ 0);
function foo($a)
{
...
How can you know from this that the first expression must be evaluated at
function entry, that the second one must be interpreted when function
exits, let alone the question of __RETURN__ replacement and external switch
to authorize/disable DbC evaluations.
If we will support such DbC approach, then an additional extension may use
this attributes to insert their code into appropriate places of main
function.
Thanks. Dmitry.
Several people rightly stated that expression would be computed at compile
time. That's a way to solve the scope question as it practically means that
expressions are evaluated in the global scope, but DbC must evaluate its
expressions at runtime. Does it mean we should write 'DbC.requires('$a
0') ? Not very intuitive but that's probably the only solution.
Something else : I am not sure I understand, but do you intend evaluating
annotation expressions everytime you parse the file. Or would you provide a
global switch ?
Any one can use doc-block now and later, but php core won't parse
doc-blocks. It's a task for external tools.
I understand. Actually, DbC is not the perfect use case for annotations.
It would be fine to find a good use case because neither of DbC, AOP,
Doctrine, or phpdoc fit so well.
There comes my last question : is it so interesting and mandatory to
implement annotations in the core, instead of an extension which would
parse doc blocks when needed, and would return bare strings through a
reflection-like API ? I know most want to put annotations in the core, but
what's the real benefit, if we don't consider performance ? Do we have use
cases comparing both approaches ?
The fact that we voluntarily make it incompatible with phpdoc and doctrine
'annotations' saddens me a bit too because people used to the current
'annotation' meaning will have to integrate that a new PHP native
'annotation' feature, totally different from what they've been using for
years. And doctrine is not an edge-case. If there are good reasons, why
not, but I don't see them yet.
Regards
François
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/16/2015 09:48 PM, Sara Golemon wrote: Second, I should clarify that while the HHVM runtime performs coersion, the hack type checker is strict. So my original statement was inaccurate. As far as hack is concerned, it's simply strict. Period. With both the default (partial) type checking and strict enabled, my number_format() example in Hack produces: ... Please correct me here if I somehow ran these incorrectly. I did put some deliberate type errors into my userspace code and hh_client caught those nicely, so it seems like it was working, but it didn't catch anything when it came to calling the internal API functions. The mechanisms are strict, but the definitions, in hack, are untyped, so there's nothing to validate: hphp/hack/hhi/stdlib/builtins_string.hhi: function number_format($number, $decimals = 0, $dec_point = ., $thousands_sep = ,); We left a lot of stuff untyped from hack's point of view precisely because so much of PHP's APIs are non-sensical. Have you looked at what chr() does with bad types lately? Yikes. So, you keep asking what I would support. I would like to see an RFC along the following lines: 1. Tighten up the type coercion for the 1000 dogs case although we have to look at whether there is a problem with some database APIs returning space-padded fields so 1000 would now break. Hopefully that is fringe enough to not break the world. Hopefully, though I think that we could embrace the idea of trailing space as insignificant. 2a. In strict mode, tone down the strictness and allow non-lossy coercion including int-float. And yes, I know in really edge cases that isn't technically non-lossy, but for all practical purposes it is. Nod. Ze'ev called for this too. 2b. A much more flexible system for specifying multiple types. I should be able to say that my function takes something that looks like a number if I choose and still take advantage of stricter typing for other parameters. Union types. I'm hear a lot of support for this concept, and not exclusively from one camp. Perhaps with a psuedo-type defined somewhere to account for the half-type numeric string. 3. Don't turn on crazy-strict mode for internal functions that weren't designed for that. Instead provide the same ability as userspace gets for developers to gradually design their APIs to be stricter if they so desire allowing both Hack and PHP to implement a stricter curl_setopt(), for example. Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode? Or something passed to the arg_info struct? The details are secondary, but you get my meaning... -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17 בפבר׳ 2015, at 18:32, Andrey Andreev n...@devilix.net wrote: Hi, On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote: If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. I agree that it doesn't give everybody what they want - it only gave weak hint supporters *all* that they want. Andrey, I'm a weak typing supporter; I want PHP to never make it easy at the language level to treat 32 and 32 differently; The RFC did exactly that. - The v0.3 RFC didn't give weak hint supporters everything they wanted. QED. Many also objected because strict typing was only opt-in and could never affect the caller's code unless the caller explicitly declares that they want to do that. You're ignoring that and you're twisting it the other way around. It's enough to provide one counter example to disprove an assertion - the assertion that the v0.3 RFC gave everyone what they wanted - and I provided the one I can personally attest to. I certainly didn't claim strict typing supporters got everything they wanted, so I'm not sure why I'm twisting anything. If anything, you're only making the point that the v0.3 RFC doesn't give everyone what they want stronger. I think the options we're discussing here take us away from this zero sum game, provides benefits to both schools of thought, and it seems to me as if you were open to it. I'd much rather we invested our energies there! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Andrey Andreev [mailto:n...@devilix.net] If we still see that employing the strict(er) rules is very noisy with internal functions, a more appropriate option may be introducing new types into ZPP, that would correspond to the new rules we introduce in the userland type hints, and requiring extension authors to explicitly move to them where they believe it's appropriate. That will allow extension authors to make their choice regarding their APIs, similarly to the process that will happen in userland. And that brings us back to square one ... Expose only 1 tool to userland, but then give two options to the much less-populated crowd of extension developers. That doesn't make sense to me. I must say 'no'. That's completely different of dual-mode, as it was not clear, but the types we would add to ZPP would be also available in userland. The objective is to maintain a full consistency between userland, internal funcs, and documentation. This is so true that we'll probably, in the future, introduce ZPP supported specialized types, like path, to userland. I am also quite sure that we'll add a set of strict types, for the few cases where zval type *really* matters (like sorting and other 'special' stuff). But we are not intending to make it more complex than needed for a first release. We all need to practice before identifying additional needs. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Tuesday, February 17, 2015 5:48 PM To: Zeev Suraski Cc: franc...@php.net; Sara Golemon; PHP internals Subject: Re: [PHP-DEV] Reviving scalar type hints Zeev et al, Because it **wasn't** a compromise (neither side had to give up anything). It gave both sides exactly what they want and need while letting them work together transparently. If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. It's not unique to this RFC either; There's a reason we don't accept all proposals, including countless ones that have zero compatibility/performance issues, just because we don't think they're a good fit for the language. Regarding your point about static analyzers, based on what I saw on this list it hardly seems that this is the main reason most proponents of strict types are interested in them. I, for one, think developer productivity is a lot more important than making life easy for static analyzers, and static analyzers should be designed around the language, not vice versa. I urge you to consider the fact that the solution that 'gives everyone what they wanted' is hardly that at all, and we're trying to find a potential compromise that will hopefully have a lot fewer people objecting to it. If we succeed, not everyone will get everything they want, but hopefully a lot more people will be able to join the yes vote. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 5:38 PM, Sara Golemon poll...@php.net wrote: On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/16/2015 09:48 PM, Sara Golemon wrote: Second, I should clarify that while the HHVM runtime performs coersion, the hack type checker is strict. So my original statement was inaccurate. As far as hack is concerned, it's simply strict. Period. With both the default (partial) type checking and strict enabled, my number_format() example in Hack produces: ... Please correct me here if I somehow ran these incorrectly. I did put some deliberate type errors into my userspace code and hh_client caught those nicely, so it seems like it was working, but it didn't catch anything when it came to calling the internal API functions. The mechanisms are strict, but the definitions, in hack, are untyped, so there's nothing to validate: hphp/hack/hhi/stdlib/builtins_string.hhi: function number_format($number, $decimals = 0, $dec_point = ., $thousands_sep = ,); We left a lot of stuff untyped from hack's point of view precisely because so much of PHP's APIs are non-sensical. Have you looked at what chr() does with bad types lately? Yikes. Wait, so Hack is actually only treating userland functions strict (and maybe the occasional internal function). This approach would immediately fix all the number_format, sin, tan problems, but again be rejected by static propononets for not being complete for analysis. We can run this circle for another time :-) So, you keep asking what I would support. I would like to see an RFC along the following lines: 1. Tighten up the type coercion for the 1000 dogs case although we have to look at whether there is a problem with some database APIs returning space-padded fields so 1000 would now break. Hopefully that is fringe enough to not break the world. Hopefully, though I think that we could embrace the idea of trailing space as insignificant. 2a. In strict mode, tone down the strictness and allow non-lossy coercion including int-float. And yes, I know in really edge cases that isn't technically non-lossy, but for all practical purposes it is. Nod. Ze'ev called for this too. 2b. A much more flexible system for specifying multiple types. I should be able to say that my function takes something that looks like a number if I choose and still take advantage of stricter typing for other parameters. Union types. I'm hear a lot of support for this concept, and not exclusively from one camp. Perhaps with a psuedo-type defined somewhere to account for the half-type numeric string. 3. Don't turn on crazy-strict mode for internal functions that weren't designed for that. Instead provide the same ability as userspace gets for developers to gradually design their APIs to be stricter if they so desire allowing both Hack and PHP to implement a stricter curl_setopt(), for example. Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode? Or something passed to the arg_info struct? The details are secondary, but you get my meaning... -Sara -- 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/17/2015 08:38 AM, Sara Golemon wrote: On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: Please correct me here if I somehow ran these incorrectly. I did put some deliberate type errors into my userspace code and hh_client caught those nicely, so it seems like it was working, but it didn't catch anything when it came to calling the internal API functions. The mechanisms are strict, but the definitions, in hack, are untyped, so there's nothing to validate: hphp/hack/hhi/stdlib/builtins_string.hhi: function number_format($number, $decimals = 0, $dec_point = ., $thousands_sep = ,); Right, so most of the internal API functions were omitted from strict typing in Hack it looks like except for some places where it made sense to selectively apply stricter checks. The RFC as it stands doesn't give us this option which is my major problem with it. Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode? Or something passed to the arg_info struct? The details are secondary, but you get my meaning... Yes, something along those lines to allow gradual and selective strictness. The internal/extension api is just another library and the authors of these library functions should have the same allowance as userspace library authors. Like you said in one reply, What's yours is yours, what's theirs is theirs. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] RFC: Expectations
On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] Reviving scalar type hints
Hi, On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Tuesday, February 17, 2015 5:48 PM To: Zeev Suraski Cc: franc...@php.net; Sara Golemon; PHP internals Subject: Re: [PHP-DEV] Reviving scalar type hints Zeev et al, Because it **wasn't** a compromise (neither side had to give up anything). It gave both sides exactly what they want and need while letting them work together transparently. If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. I agree that it doesn't give everybody what they want - it only gave weak hint supporters *all* that they want. Many also objected because strict typing was only opt-in and could never affect the caller's code unless the caller explicitly declares that they want to do that. You're ignoring that and you're twisting it the other way around. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
Alexander Lisachenko wrote on 17/02/2015 14:21: 2015-02-17 16:35 GMT+03:00 Rowan Collins rowan.coll...@gmail.com mailto:rowan.coll...@gmail.com: The other alternative is to go to the other extreme, and have the extensions scoped to a particular file, more like Perl pragmas. Dare I say we could use the declare() syntax that everyone seems to have an irrational hatred of? declare(pragma=Example\DbcParserExtension); Ouch ) Don't like this way at all, because extensions should process all files, even if it's not marked with some hints. What I want to see is PHP analog of Java bytecode compilers, they can transform an original source code into specific tokens and provide custom extensions on top of that. So, I want to choose between php.ini option and explicit methods. Let's see another opinions. It's interesting that you used the word extension there. If the hook can only be registered for in php.ini (and it would need to be PHP_INI_SYSTEM if you want to avoid OpCache needing to vary its cache on different settings) then these are basically extensions which happen to be written in PHP - you install them globally, they execute unconditionally, and they do things which can't be done any other way. In that case, it would maybe make more sense to make this part of the simplified extension API discussed in a previous thread, rather than exposing it to userland at all. The only abilities you'd lose are ones which should never be used anyway, e.g. statically registering an extension, then dynamically changing its behaviour at runtime by altering global/static variables. I think the same argument applies to per-file pragmas over per-install settings, as to Dependency Injection over global state - you should be able to reason about each module of code in isolation, reuse it in different combinations, etc, etc. What if you want to use two different DbC extensions on the same server, and they collide with each other? What would the error look like if you failed to install an extension that was required to process your source code as intended? A declare line (or Perl's use, or Python's import) gives a clear point where that requirement is defined. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 10:15 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@zend.com wrote: hi, During discussion of different ways of implementing Design by Contract we got an idea of using annotations. BTW: annotations are useful by their own and may be used for different purposes. Support for annotations was proposed long time ago: https://wiki.php.net/rfc/annotations https://wiki.php.net/rfc/annotations-in-docblock https://wiki.php.net/rfc/reflection_doccomment_annotations HHVM already implemented similar concept http://docs.hhvm.com/manual/en/hack.attributes.php I made a quick and dirty PoC that shows how we may implement annotations in PHP7 and how powerful they may be : https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2 How about not exposing the AST, and then the userland can pass context to a method $reflection-getAnnotation($name, $context); https://gist.github.com/beberlei/0dc36d4412b8e3454912 That way AST is not exposed to userland. Your example handles just particular use-case. I would like to provide a general solution. Thanks. Dmitry. Could you provide some more info on how you would imagine this to be used for the DbC use case? As far as I see, this would require injecting code into the method body based on the annotations. Does that mean that annotations handlers will get the chance to modify the AST of the method itself during compilation? Or how is this supposed to be realized? In general, it must be possible to plug into compilation process using zend_ast_process() callback and modify function AST, inserting constraints validation in proper places. But for now, I'm thinking only about metadata syntax and representation. I just showed, how it can be used to represent DbC constraints. I don't think we need user-level interface to modify AST. To make sure I got it right: The AST-based annotations are only there to allow handling by PHP extensions (or the engine itself), while evaluated annotations are there for use by userland code? Nikita
Re: [PHP-DEV] Reviving scalar type hints
Am 17.02.2015 um 12:30 schrieb Leigh: And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? As the library author you will never ever notice if your library was called in strict mode or not! And that is the point: you will not get any gain from making all your parameters strict, you will just force the user to cast (as Rasmus said already). Repeating that strict mode is required from a library author's point of view does not make it right. You always get the types you want, you just limit the library consumer. But you may want your code call other functions in strict mode to catch some type errors, that is perfectly valid, I don't deny that. Thanks Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : Zeev Suraski [mailto:z...@zend.com] Even though that's not what I meant when I sent my proposal in the morning, Sorry, I was not clear enough : it was my position only. I've been wondering about the same thing (also with the feedback from Dmitry). Can go an extra step from both directions, and come up with a rule set that is stricter than the currently proposed weak hinting, but not as strict as the currently proposed strict hinting? Key challenge I see with that is that scalar type hinting would go farther apart from our implicit casting rules. However, the current RFC already aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting Apple as an int). Choosing between that and having two separate modes, I think that's the better option. ZPP already chose a while ago to implement a much restricted conversion set from convert_to_xxx() rules. The objective is not the same, as casting must be as permissive as possible (we could discuss that in the future too...). I hope we all agree to keep scalar type hinting aligned on ZPP rules. I also think we all agree, while implicitely, on the ruleset changes we're expecting. I am currently writing this down, so that we have a written base to discuss. Just one detail, to be sure we are in sync : new conversion rules will remain in sync between zend_parse_parameters() and zpp, while future additional types will be defined in zpp only. I assume we are OK to refuse extending the zend_parse_parameters() format in the future. I think that practically speaking, that is incorrect, at least from my experience with PHP developers. They do differentiate between built-in functions and userland functions. There are some fundamental differences between the two (being able to find their code, step into them in a debugger, find docs on php.net, etc.). As I mentioned earlier, the fundamental difference between built-in functions and userland functions in the context of our discussion is that if we introduce userland type hints, nothing happens before people change their code, and make (hopefully) informed decisions about what type hints to add, if any. No such luck with built-in functions, which have type information associated, built collectively over the last two decades. As Rasmus demonstrated, flipping that switch on for built-in functions results in a lot of work to 'clean' the code up, but you end up with having code that's not necessarily any better. That said, it's quite possible that the situation will be much improved if when we implement the less-strict rules we're proposing here, which would accept 32 as an integer or 37 as a float. I fully agree with you and Rasmus. Strict typing, as defined in 0.3, does not fit with internal functions. To summarize, we have two options : - differentiate behavior and run weak checks on internal functions, even if strict switch is on. - attempt to get back to a single-mode mechanism, which would keep both worlds in sync. I definitely prefer to explore the second one. If we still see that employing the strict(er) rules is very noisy with internal functions, a more appropriate option may be introducing new types into ZPP, that would correspond to the new rules we introduce in the userland type hints, Why not, but let's first try avoiding it first, as we'll bikeshed during weeks on the syntax for new keywords. Remember that class names share the same naming space as type hint keywords. So, defining new keywords will lead to endless discussions. And stating, as I heard, that we just have to use lowercase-only keywords, is not serious. That's a little off-topic here, but I would also propose to deprecate using bare class names as type hints from 7.0. That's a big BC change and a lot will hate that, but the issue was created when the 'array' type hint was added, and we need to fix it (proposing an alternate syntax like 'object(classname)'). As long as we support bare class names, adding a new type is almost impossible and typedef is *totally* impossible. It's just deprecating, but the impact is such that it can come with a major version only. A smoother path can be to introduce the alternate syntax in 7.0, then deprecate in 7.1 or 7.2. It will take more time but it's probably better. union types can be kept for the future if we don't go the nullable road, as it would be too confusing making 'string|null' and '?string' synonyms. I think we all agree about that. Fine :) ! Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
Alexander Lisachenko wrote on 17/02/2015 12:41: 2015-02-17 15:29 GMT+03:00 Benjamin Eberlei kont...@beberlei.de: Well not really, depending on the path towards a require a parser extension is already registered or not. Or you have conditional registration of extensions. So you could load a file with an extension registered, but it still serves the old opcodes for that file. Technically, this will be possible, however, Parser Extensions should be registered ASAP during bootstrap process, near spl_autoload_register(), stream_wrapper_register(), stream_filter_register(), etc.. I think should is OK for extensions, but not for userland hooks. There needs to be a very firm definition of the right and wrong way to implement these hooks, which can at the very least warn the user when they are slipping into undefined behaviour. Note that spl_autoload_register doesn't affect OpCache because it only changes the mapping of a class to a parsed file (keyed on the file system path to the source), not the compiled contents of that file. If AST hooks can be registered on a global scope at any time, then compiling the same file can lead to different op codes at different times (e.g. page loads which take a different path through the code), which would mean the OpCache would need extra information in its keys to cache each possible version. One more possible way for this RFC is to remove these register/unregister methods from the `Php\Parser\Engine` class and add an option to the php.ini with list of classes to load. This option can be adjusted then per project/directory. Is this more suitable? The other alternative is to go to the other extreme, and have the extensions scoped to a particular file, more like Perl pragmas. Dare I say we could use the declare() syntax that everyone seems to have an irrational hatred of? declare(pragma=Example\DbcParserExtension); Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Hi, On Tue, Feb 17, 2015 at 5:02 PM, Dennis Birkholz den...@birkholz.biz wrote: Am 17.02.2015 um 12:30 schrieb Leigh: And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? As the library author you will never ever notice if your library was called in strict mode or not! And that is the point: you will not get any gain from making all your parameters strict, you will just force the user to cast (as Rasmus said already). Repeating that strict mode is required from a library author's point of view does not make it right. You always get the types you want, you just limit the library consumer. But you may want your code call other functions in strict mode to catch some type errors, that is perfectly valid, I don't deny that. What you've said has been repeat tens of times already. Many of us just disagree with that rationale, because it's missing the point. Nobody is stupid enough not to know that they always receive the specified type. There's just a big difference between knowing that you will receive a i.e. boolean, and knowing that the user *passed* a boolean. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 14:49, Andrey Andreev wrote: I agree. It's more of a question of eliminating potentially dangerous conversions than just being lossless. Agreed as well. However, while bool - int conversion one of the reasons why many people want strict type-hints, it also often makes sense and is quite widespread. There's no silver bullet for that problem. Returning 'not-zero/empty' as true and 'zero' as false is one of the natural things to use in PHP and I don't think any other language has that flexibility? It is also why some of the other 'little changes' such as hard coded IS_TRUE and IS_FALSE are actually somewhat alien! Certainly is does not play well with my methods of working, but then I prefer a function to return a result rather than crash out with an exception ... Although -ve values are even more useful than a simple 'zero' return and that may replace a string return. -- 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] Reviving scalar type hints
On Tue, Feb 17, 2015 at 1:30 PM, Leigh lei...@gmail.com wrote: On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote: We can sigh and tut about this not being the PHP way, but the script author was the one who chose to enter into a tight contract, and the script author, not you, is the one who should have that authority over their own application. I find this view way too extreme. You find giving authority over an application to the application author too extreme? And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? I'm sure I could find a way of detecting non-strict mode and throw a fatal, or force access through a facade/wrapper of some sort where I've turned on strict and made myself the caller. Isn't this equally unhelpful? The point is some people will want strict turned on, and they will find ways to force it on people. You're going to have to live with it, so just make it a possibility from the outset. ^ That. I've said the same thing multiple times already. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Hi, On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: François Laupretre [mailto:franc...@php.net] Sent: Tuesday, February 17, 2015 2:58 PM To: 'Sara Golemon'; 'Zeev Suraski' Cc: 'PHP internals' Subject: RE: [PHP-DEV] Reviving scalar type hints 2. It is not not about being lossless or not. People expect bool - int to be disabled, for example, and it is not lossless. 3. It is more a question of finding a consensus about conversions which don't make sense, and disabling them. Examples include bool conversion to any other type and, of course, disabling trailing chars in numeric strings. I agree. It's more of a question of eliminating potentially dangerous conversions than just being lossless. Agreed as well. However, while bool - int conversion one of the reasons why many people want strict type-hints, it also often makes sense and is quite widespread. There's no silver bullet for that problem. 4. Once this is done, 99% of strict type proponents already said they would be OK with the so-called (not so) weak mode, making it possible to get rid of this far from perfect two-mode mechanism (actually, this two-mode approach more and more reminds me a great idea about bringing transparent Unicode support in PHP). Even though that's not what I meant when I sent my proposal in the morning, I've been wondering about the same thing (also with the feedback from Dmitry). Can go an extra step from both directions, and come up with a rule set that is stricter than the currently proposed weak hinting, but not as strict as the currently proposed strict hinting? Key challenge I see with that is that scalar type hinting would go farther apart from our implicit casting rules. However, the current RFC already aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting Apple as an int). Choosing between that and having two separate modes, I think that's the better option. I don't think it has 99% support, but surely better than the dual-mode approach indeed. But is it the best solution? The dual-mode approach was suggested because there is need and demand for *two* kinds of type-hinting. Most of the controversy and criticism came from the fact that introduces a switchable mode, while most of the praise received was due to somebody finally proposing *both* solutions at the same time. * Exclude internal functions from the strict switch. (Perhaps have a separate switch for internal functions at a later date) This would make the feature inconsistent from an end user's pov. If a user enables strict mode, he assumes strict checks for every function he calls. *We* know that userspace and internal functions use different mechanisms, but the end user doesn't have to know. From his pov, a function is a function. I think that practically speaking, that is incorrect, at least from my experience with PHP developers. They do differentiate between built-in functions and userland functions. There are some fundamental differences between the two (being able to find their code, step into them in a debugger, find docs on php.net, etc.). As I mentioned earlier, the fundamental difference between built-in functions and userland functions in the context of our discussion is that if we introduce userland type hints, nothing happens before people change their code, and make (hopefully) informed decisions about what type hints to add, if any. No such luck with built-in functions, which have type information associated, built collectively over the last two decades. As Rasmus demonstrated, flipping that switch on for built-in functions results in a lot of work to 'clean' the code up, but you end up with having code that's not necessarily any better. Complely agree with that statement. I tried to explain the same thing multiple times already ... unfortunately with no success. That said, it's quite possible that the situation will be much improved if when we implement the less-strict rules we're proposing here, which would accept 32 as an integer or 37 as a float. That might work, if we're indeed looking for a compromise. If we still see that employing the strict(er) rules is very noisy with internal functions, a more appropriate option may be introducing new types into ZPP, that would correspond to the new rules we introduce in the userland type hints, and requiring extension authors to explicitly move to them where they believe it's appropriate. That will allow extension authors to make their choice regarding their APIs, similarly to the process that will happen in userland. And that brings us back to square one ... Expose only 1 tool to userland, but then give two options to the much less-populated crowd of extension developers. That doesn't make sense to me. So, from all these arguments, I now think that strict types, as defined in 0.3, are not the best solution. With option to
RE: [PHP-DEV] Reviving scalar type hints
De : Lester Caine [mailto:les...@lsces.co.uk] Returning 'not-zero/empty' as true and 'zero' as false is one of the natural things to use in PHP and I don't think any other language has that flexibility? You didn't read it right. I was talking of conversions *from* bool, not *to* bool. (int - bool) is fine and will be preserved, but I propose to remove (bool - int). You will still return numbers as bool, and non-zero will still be converted to true. Relax :) Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Zeev et al,
2. It is not not about being lossless or not. People expect bool - int to
be
disabled, for example, and it is not lossless.
3. It is more a question of finding a consensus about conversions which
don't
make sense, and disabling them. Examples include bool conversion to any
other type and, of course, disabling trailing chars in numeric strings.
I agree. It's more of a question of eliminating potentially dangerous
conversions than just being lossless.
Disagree. For a weak-mode, that does solve the problems that many
people want solved. But it also ignores a lot of the problems that the
strict crowd want solved.
Let me show by example:
function convertToInt(string $number): int {
if (!preg_match((^[0-9]{1,17}$), $number)) {
throw new InvalidArgumentException(Supplied argument is not a
valid number);
}
return $number;
}
From a weak standpoint that looks like it should work. And from a
pragmatic standpoint it should work as well. But from a static
analysis standpoint, we can't tell.
A static analyzer (one of the reasons people want strict) would error
there. The reason is that *at compile time* it can't reason about the
code well enough to determine if there's an error or not. You're
passing a string where you expect an int. Is that going to work? We
don't know. So the analyzer would need to throw a warning that the
cast is potentially unsafe because it can't guarantee that the runtime
won't throw an error. Which means that to remove the warning you'd
need to add an explicit cast.
At which point what does the weak mode buy us?
Instead, if we make the strict mode behave based on types alone, this
wouldn't be a problem (because we can detect ahead of time to 100%
accuracy type errors in the strict mode files). And hence prevent
errors at build time, rather than detecting them at runtime in prod.
associated, built collectively over the last two decades. As Rasmus
demonstrated, flipping that switch on for built-in functions results in a
lot of work to 'clean' the code up, but you end up with having code that's
not necessarily any better. That said, it's quite possible that the
situation will be much improved if when we implement the less-strict rules
we're proposing here, which would accept 32 as an integer or 37 as a
float.
And
Every option has pros and cons. Since it's clear beyond a reasonable doubt
that we can't all agree on purely weak type hints and equally on purely
strict type hints, it becomes a question of what is the right compromise.
Adding both - which at least from my point of view has major drawbacks (too
prominent zval.type exposure; complexity of two systems; internal
functions issue). Creating something in between that would handle most if
not all of the use cases the strict camp brought up, while not (IMHO) overly
focusing on zval.type and making things a lot more noisy/complex for
built-in functions - is a better direction, whose advantage - I think -
outweigh its disadvantages.
Again, that changes the type checks from type checks to value checks.
Which is fine for a weak mode (default mode of operation), but
really throws away a large part of what many strict proponents
want/need. And they won't be able to be satisfied unless zval.type is
exposed fully. Because that's the point of strict typing and static
analysis (and hence any compromise away from it reduces the value of
the type hint to nothing).
What you call issues, I call strengths. The internal functions issue
is not really an issue at all to me because that's the entire point of
type safety. And the fact that internal functions are already built-in
with it is a bonus, not a drawback.
The right compromise is the system that Andrea built. Because it
**wasn't** a compromise (neither side had to give up anything). It
gave both sides exactly what they want and need while letting them
work together transparently. That doesn't sound like a compromise to
me. That sounds like an innovative and ingenious design. And the fact
that it hovered around 2/3 support the entire time shows that. Not to
mention that several people (Daniel and Levi specifically, but others
as well) *only* voted against it because of the declare semantics.
There are a few details that should be worked out:
1. The switch syntax, as Sara straw-polled for (my vote is
declare(strict_types=true) at the top of the file only)
2. The behavior of numeric types.
Now, it's been said before here on this list that No other language
is this strict about types. And that's patently false. I've done some
research across major typed languages:
VB, C and C++: Allows almost freeform movement between numeric types:
http://en.cppreference.com/w/cpp/language/implicit_cast
Java, D, C# and Pascal follow widening primitive style rules:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2
It allows only a widening primitive conversion. That means that you
can call a function wanting a float and
RE: [PHP-DEV] Reviving scalar type hints
-Original Message-
From: François Laupretre [mailto:franc...@php.net]
Sent: Tuesday, February 17, 2015 2:58 PM
To: 'Sara Golemon'; 'Zeev Suraski'
Cc: 'PHP internals'
Subject: RE: [PHP-DEV] Reviving scalar type hints
2. It is not not about being lossless or not. People expect bool - int to
be
disabled, for example, and it is not lossless.
3. It is more a question of finding a consensus about conversions which
don't
make sense, and disabling them. Examples include bool conversion to any
other type and, of course, disabling trailing chars in numeric strings.
I agree. It's more of a question of eliminating potentially dangerous
conversions than just being lossless.
4. Once this is done, 99% of strict type proponents already said they
would
be OK with the so-called (not so) weak mode, making it possible to get rid
of
this far from perfect two-mode mechanism (actually, this two-mode
approach more and more reminds me a great idea about bringing
transparent Unicode support in PHP).
Even though that's not what I meant when I sent my proposal in the morning,
I've been wondering about the same thing (also with the feedback from
Dmitry). Can go an extra step from both directions, and come up with a rule
set that is stricter than the currently proposed weak hinting, but not as
strict as the currently proposed strict hinting?
Key challenge I see with that is that scalar type hinting would go farther
apart from our implicit casting rules. However, the current RFC already
aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting
Apple as an int). Choosing between that and having two separate modes, I
think that's the better option.
* Exclude internal functions from the strict switch. (Perhaps have a
separate switch for internal functions at a later date)
This would make the feature inconsistent from an end user's pov.
If a user enables strict mode, he assumes strict checks for every function
he
calls. *We* know that userspace and internal functions use different
mechanisms, but the end user doesn't have to know. From his pov, a
function
is a function.
I think that practically speaking, that is incorrect, at least from my
experience with PHP developers. They do differentiate between built-in
functions and userland functions. There are some fundamental differences
between the two (being able to find their code, step into them in a
debugger, find docs on php.net, etc.).
As I mentioned earlier, the fundamental difference between built-in
functions and userland functions in the context of our discussion is that if
we introduce userland type hints, nothing happens before people change their
code, and make (hopefully) informed decisions about what type hints to add,
if any. No such luck with built-in functions, which have type information
associated, built collectively over the last two decades. As Rasmus
demonstrated, flipping that switch on for built-in functions results in a
lot of work to 'clean' the code up, but you end up with having code that's
not necessarily any better. That said, it's quite possible that the
situation will be much improved if when we implement the less-strict rules
we're proposing here, which would accept 32 as an integer or 37 as a
float.
If we still see that employing the strict(er) rules is very noisy with
internal functions, a more appropriate option may be introducing new types
into ZPP, that would correspond to the new rules we introduce in the
userland type hints, and requiring extension authors to explicitly move to
them where they believe it's appropriate. That will allow extension authors
to make their choice regarding their APIs, similarly to the process that
will happen in userland.
So, from all these arguments, I now think that strict types, as defined in
0.3,
are not the best solution.
With option to introduce features such as the following at a later date:
* Union types (e.g. function foo((int | float) $value): (bool |
string) { ... })
* Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as
standard (like numeric), others user-definable)
As I told Zeev, union types can be kept for the future if we don't go the
nullable road, as it would be too confusing making 'string|null' and
'?string'
synonyms.
I think we all agree about that.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? Nikita
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 7:02 AM, Dennis Birkholz den...@birkholz.biz wrote: Am 17.02.2015 um 12:30 schrieb Leigh: And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? As the library author you will never ever notice if your library was called in strict mode or not! And that is the point: you will not get any gain from making all your parameters strict, you will just force the user to cast (as Rasmus said already). No, and Rasmus examples, while being technically correct for some of them, just add confusions to the stack. The caller, and the calls to internals function in the caller codes, won't be affected, at all. Please understand it. Only the library code will. Now we can surely find other cases where we may adapt the patch or be more obvious, but for my own sake, get over this it will break and change everything everywhere, it does not. Repeating that strict mode is required from a library author's point of view does not make it right. You always get the types you want, you just limit the library consumer. No, you do not. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Annotations in PHP7
HI Dmitry,
Question : in which scope do you evaluate the PHP expression ?
Example :
DbC.requires($a 0);
DbC.ensures(__RETURN__ 0);
function foo($a)
{
...
How can you know from this that the first expression must be evaluated at
function entry, that the second one must be interpreted when function exits,
let alone the question of __RETURN__ replacement and external switch to
authorize/disable DbC evaluations.
Several people rightly stated that expression would be computed at compile
time. That's a way to solve the scope question as it practically means that
expressions are evaluated in the global scope, but DbC must evaluate its
expressions at runtime. Does it mean we should write 'DbC.requires('$a 0')
? Not very intuitive but that's probably the only solution.
Something else : I am not sure I understand, but do you intend evaluating
annotation expressions everytime you parse the file. Or would you provide a
global switch ?
Any one can use doc-block now and later, but php core won't parse doc-blocks.
It's a task for external tools.
I understand. Actually, DbC is not the perfect use case for annotations. It
would be fine to find a good use case because neither of DbC, AOP, Doctrine, or
phpdoc fit so well.
There comes my last question : is it so interesting and mandatory to implement
annotations in the core, instead of an extension which would parse doc blocks
when needed, and would return bare strings through a reflection-like API ? I
know most want to put annotations in the core, but what's the real benefit, if
we don't consider performance ? Do we have use cases comparing both approaches ?
The fact that we voluntarily make it incompatible with phpdoc and doctrine
'annotations' saddens me a bit too because people used to the current
'annotation' meaning will have to integrate that a new PHP native 'annotation'
feature, totally different from what they've been using for years. And doctrine
is not an edge-case. If there are good reasons, why not, but I don't see them
yet.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Andrey Andreev [mailto:n...@devilix.net] Sent: Tuesday, February 17, 2015 4:49 PM To: Zeev Suraski Cc: franc...@php.net; Sara Golemon; PHP internals Subject: Re: [PHP-DEV] Reviving scalar type hints Hi, On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski z...@zend.com wrote: I agree. It's more of a question of eliminating potentially dangerous conversions than just being lossless. Agreed as well. However, while bool - int conversion one of the reasons why many people want strict type-hints, it also often makes sense and is quite widespread. There's no silver bullet for that problem. I'm not sure we need a silver bullet. If the conversion and acceptance rules are clear and reasonable, it's an entirely valid outcome that in cases where both int and bool are equally acceptable, you won't use a type hint but rather explicitly cast to int inside the function. But is it the best solution? The dual-mode approach was suggested because there is need and demand for *two* kinds of type-hinting. Most of the controversy and criticism came from the fact that introduces a switchable mode, while most of the praise received was due to somebody finally proposing *both* solutions at the same time. Every option has pros and cons. Since it's clear beyond a reasonable doubt that we can't all agree on purely weak type hints and equally on purely strict type hints, it becomes a question of what is the right compromise. Adding both - which at least from my point of view has major drawbacks (too prominent zval.type exposure; complexity of two systems; internal functions issue). Creating something in between that would handle most if not all of the use cases the strict camp brought up, while not (IMHO) overly focusing on zval.type and making things a lot more noisy/complex for built-in functions - is a better direction, whose advantage - I think - outweigh its disadvantages. If we still see that employing the strict(er) rules is very noisy with internal functions, a more appropriate option may be introducing new types into ZPP, that would correspond to the new rules we introduce in the userland type hints, and requiring extension authors to explicitly move to them where they believe it's appropriate. That will allow extension authors to make their choice regarding their APIs, similarly to the process that will happen in userland. And that brings us back to square one ... Expose only 1 tool to userland, but then give two options to the much less-populated crowd of extension developers. That doesn't make sense to me. First, let us hope that the situation will be much better to a level that we don't need to go in that direction :) But that said, I don't quite see it in the same way. Internal functions already commonly use a lot more advanced type checking than is commonly found in userland functions. Functions that behave differently depending on the type of argument you pass, on the number of arguments, etc. While technically it's possible to achieve in userland, it's a lot less common. So while I do see an issue here, I don't think it's *that* bad if it has to come to that. Unless we find out our rules work nicely out of the box for internal functions (which I'm still somewhat hopeful for) - there's no way to reconcile the fact that internal functions come with this long history of having detailed type data, while userland functions do not... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
Hello, Lars! 2015-02-17 22:09 GMT+03:00 Lars Strojny l...@strojny.net: Looks cool and I could see a couple of interesting possibilities arising. One thing: any particular reason ExtensionInterface is static? I could see a couple of benefits having extensions carry state and registerExtension() taking an instance of ExtensionInterface, not a class name. What do you think? Thanks for the positive feedback! My first thought was to use instances for extensions: https://gist.github.com/lisachenko/ffcfdec4c46e01864b33. However, I have a doubts that this will introduce additional possibilities for side-effects, when extensions can be configured differently/loaded/unloaded. In this thread some people noticed this fact too and suggested to add a restrictions for preventing conditional parsing of the source code. So, static method and static registration was chosen to reduce a number of possible conditional extensions. This has some disadvantages (testing, configuration, etc), but should give better experience with parsing behavior.
RE: [PHP-DEV] Reviving scalar type hints
De : Lester Caine [mailto:les...@lsces.co.uk] My current practice up until now has been to use 'return false' when an action failed, but the main return would be a number of records or string of data. So you are now blocking that activity ... I'm reading to right, but you are not thinking all possibilities through. But I think I'm starting to see it broken already with the other changes to the core :( I'm not returning 'IS_FALSE' so I'm probably going to have to change the 'false' to '0' anyway so as to avoid the bool? Hi Lester, I am not blocking anything. My objective is to provide union types. Using union types, you will declare your return type as 'int|bool'. That's why I was pushing to integrate this feature in the first release. It will be done if we have enough time, but it is a lot to integrate in a discussion that must be quite short, as time is restricted. I am surely not thinking all possibilities :) but returning integer or false is usual and in scope. The solution is not to authorize (bool - int) conversion (as it would have to support (bool - anything)), but support 'int|bool', 'resource|bool', and similar syntax. So, the solution is completely different from the (int - bool) question. Even, if we don't release union types in 7.0, it will be clearly stated that it is a required follow-up. That's not perfect but we do it as fast as we can and everyone is welcome to help. What does this mean in your case ? Just that, as long as the feature is not available, your function won't have an explicit return type. Period. And, please, don't change false to 0 ;). Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : François Laupretre [mailto:franc...@php.net]
This way, the user can write :
function convertToInt(string $number): int! { - int! instead of int
if (!preg_match((^[0-9]{1,17}$), $number)) {
throw new InvalidArgumentException(Supplied argument is not a valid
number);
}
return $number;
A static analyzer would raise an error on this, as we are sure it fails, while :
function convertToInt(string $number): int! {
if (!preg_match((^[0-9]{1,17}$), $number)) {
throw new InvalidArgumentException(Supplied argument is not a valid
number);
}
return (int)$number;
would be analyzed as OK. That's what you want, don't you ?
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
Yes, I already know that. The difference, and why I keep pointing that out, is that me and many others want strict typing for our own reasons (but still in its entirety instead of as a limited mode) and most of us don't even care if you getting weak typing for your own usage. You can't work towards consensus if your target is to prevent the opposing group of getting what they want. I see both as valuable tools for different jobs and I want to have more tools at my disposal, while you're trying to tell me that I should use only one tool for everything. First, it's very important to understand that my target is to prevent the opposing group from getting what they want. I'm really not sadistic :) My reasons were obviously different and worked towards a different goal. Much in the same way that people who vote against an RFC - one of the countless that were voted against - don't do that to hurt the ones who support it. They do it because they think adding it would bring negative consequences. I never believed the 'You don't have to use it' as a silver bullet explanation for why it's OK to add features with potentially negative implications. The good news is that I think that in many ways the ideas we're toying with right now are better for the strict-type camp, especially if we end up going for just one mode, and meet roughly mid-way in terms of strict and weak - which I think is doable. The biggest gripes strict campers had with weak mode are gone in this proposal, and unlike v0.3 - that would actually be the default (and only) behavior, which is a big gain for the strict campers. And the most prominent features of weak typing are kept (dynamic type conversion where it makes sense), hopefully making the weak campers happy too. But you implied that most objections were from people who don't want strict typing in PHP at all. And I disagree with that because it's a speculation, which in turn you are using to favor your weak-hints-only case (hence, twisting it in another direction). I didn't imply it now (at least I certainly didn't intend to). I did outright say it a week or two ago, and still believe that's the case but reached the conclusion that none of us would gain anything from further discussing it. We won't know unless we start actually polling the people who voted and ask, which we're not going to do, and we're obviously not going to convince each other. Much more importantly, it at least *seems* as if we have a direction for something that a very wide audience may rally behind. Let's focus on that! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
I like 2) No possible confusion, and it's a clear tag. I agree, but it feels like it gets away from PHP's underscore-heavy syntax. The poll omitted ?php_strict -- that feels most PHP to me. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon 1. Tighten up the type coercion for the 1000 dogs case although we have to look at whether there is a problem with some database APIs returning space-padded fields so 1000 would now break. Hopefully that is fringe enough to not break the world. Hopefully, though I think that we could embrace the idea of trailing space as insignificant. I'll propose *leading* and *trailing* whitespaces :) This doesn't cost much and can prove useful. 2b. A much more flexible system for specifying multiple types. I should be able to say that my function takes something that looks like a number if I choose and still take advantage of stricter typing for other parameters. Union types. I'm hear a lot of support for this concept, and not exclusively from one camp. Perhaps with a psuedo-type defined somewhere to account for the half-type numeric string. 'numeric' can be implemented in two ways : a union type, or a new zpp type. I think I prefer the flexibility of union types. Maybe we'll have to include it in the first release, finally :) 3. Don't turn on crazy-strict mode for internal functions that weren't designed for that. Instead provide the same ability as userspace gets for developers to gradually design their APIs to be stricter if they so desire allowing both Hack and PHP to implement a stricter curl_setopt(), for example. Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict mode? Or something passed to the arg_info struct? The details are secondary, but you get my meaning... I prefer defining four new 'strict' ZPP types for int, float, bool, and string (others are already strict). This way, the function decides what it accepts, not the user. Anyway, if we implement union types as strict-only, we will need these types. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC Proposal
Dear PHP internals, this is my first RFC proposal and I am not sure if in this email is supposed to contain all RFC details or just a brief idea .. which is to drop PHP constants in favour of “final immutable variables. This is basically only a concept but I can also handle its implementation. Please let me know if I have to provide any additional details. Regards, Tim -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
Hi, Starting making the strict mode weaker is nonsense. It is not just Rasmus' example. Which exception do you authorize then ? Would you define a third 'pseudo-strict' mode ? And about static analyzers, will they be 'pseudo-strict' too ? No, if you want strict, it can only remain purely strict. I can understand the 'strict' position, but not the desire to make it weaker. Do you understand that, starting from the purely-strict position, I can give you use cases which will cause you to define additional exceptions, until you get the same conversion rules as I am currently defining ! The only difference is that I don't claim it being 'strict'. And 'numeric' is either a new ZPP type, or an alias for a future union type. Nothing to do with pure strict mode. These are all hacks trying to solve specific use cases. Regards François -Message d'origine- De : Jordi Boggiano [mailto:j.boggi...@seld.be] Envoyé : mardi 17 février 2015 17:26 À : internals@lists.php.net Objet : Re: [PHP-DEV] Reviving scalar type hints On 17/02/2015 15:47, Anthony Ferrara wrote: If we want to add a numeric type as a virtual union of int and float, that's one way to solve the concern. If we don't, we could also allow widening primitive conversion (int - float). That wouldn't work well with bigints, but would be fine in other cases. But there are plenty of languages that always require explicit type conversion. So even if we choose that, we're in good company. As far as I understand, allowing int - float would help fix a few of Rasmus' (or was it Benjamin?) concerns about things like sin() requiring floats in strict mode. It would make strict mode a lot more usable with C code as well. +1 on keeping the strictness benefits and remove some of the drawbacks. Having numeric in addition might be nice mostly for return values I guess, but it seems a bit redundant to me if int - float is allowed. As for the straw poll, I also think declare() is the clearest syntax, especially if it's enforced to appear at most once and on top of the file to remove any potential misuses. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- 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] Annotations in PHP7
2015-02-17 19:25 GMT+03:00 Dmitry Stogov dmi...@zend.com: I think yes, However, Alexander thinks differently https://wiki.php.net/rfc/parser-extension-api Of course this is not for 7.0 This RFC consists of two parts: parsing API and parser extension API. Last one can be rejected, however it can be perfectly connected with annotation RFC (if AST will be used as values) As for annotations, general use-case is appreciated. This can be extended later in future versions of PHP. Therefore, annotation syntax should allow to define key and values. Value can be valid expression (AST? concrete node? compiled value?) or can recursively contain nested annotations.
RE: [PHP-DEV] RFC Proposal
Hi Tim, I imagine you're proposing to drop class constants only, not PHP constants ? If you want to drop PHP constants, stop wasting your time on this :) While that's the place to discuss it before you start an RFC, the concept is a little short. Could you give at least syntax examples and, most important, the migration path you imagine : would you keep supporting current constants, would you deprecate them, the BC breaks it would introduce... If you don't provide this, none can tell you if it has a chance. Regards François -Message d'origine- De : Tim Bezhashvyly [mailto:tim.bezhashv...@gmail.com] Envoyé : mardi 17 février 2015 18:35 À : internals@lists.php.net Objet : [PHP-DEV] RFC Proposal Dear PHP internals, this is my first RFC proposal and I am not sure if in this email is supposed to contain all RFC details or just a brief idea .. which is to drop PHP constants in favour of “final immutable variables. This is basically only a concept but I can also handle its implementation. Please let me know if I have to provide any additional details. Regards, Tim -- 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
Le Tue, 17 Feb 2015 00:58:18 +0100, Sara Golemon poll...@php.net a écrit: On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net wrote: Once again, anyone can take over version 0.3, if it is so great. Why don't you do it ? I will play the game, stop working on my proposal, and vote 'yes' again. But don't ask me to do it in your place. If nobody else does it, I will. I think Andrea's 0.3 proposal was extremely well balanced, served everyone's needs whether they would admit it or not, and who's only failing (subjectively termed) was the use of declare(). I think declare() is fine and not nearly as ugly as some have slandered it to be, but I'm willing to read the winds and modify it for v0.4. Straw poll: 1) ?php strict; 2) ?php-strict 3) use strict; (psuedo-namespace) 3) ?php // strict (I don't actually like HHVM's style, but if you do...) 4) declare(strict=true); (As a top-level declare only) 5) declare(strict=true); (exactly as in v0.3 -- maybe you liked it) 6) your write-in vote here I'm not going to scope in union types, nullables, or falsables. We can leave that for a followup RFC, this one is contentious enough as it is. -Sara I like 2) No possible confusion, and it's a clear tag. But implementing 3) would be a good thing, since it is Hack syntax. Even if I don't like to use comments to enable something. If we have 2 similar features between PHP and Hack, I think it should have the same syntax, so there are minimum BC from one language to another, and people would spend less time to remember which syntax is the right syntax for PHP or Hack. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
Hi Alexander, On 17 Feb 2015, at 12:46, Alexander Lisachenko lisachenko...@gmail.com wrote: Hello, internals! I want to introduce a RFC for providing a userland API for accessing an Abstract Syntax Tree of the source code and to provide userland parser hooks for source code modification: https://wiki.php.net/rfc/parser-extension-api Looks cool and I could see a couple of interesting possibilities arising. One thing: any particular reason ExtensionInterface is static? I could see a couple of benefits having extensions carry state and registerExtension() taking an instance of ExtensionInterface, not a class name. What do you think? cu, Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Exceptions in the engine
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('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.
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.
That has absolutely nothing to do with OO vs procedural code, though.
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.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote: We can sigh and tut about this not being the PHP way, but the script author was the one who chose to enter into a tight contract, and the script author, not you, is the one who should have that authority over their own application. I find this view way too extreme. You find giving authority over an application to the application author too extreme? And you find taking authority over a library away from the library author completely acceptable? If I write an API that works perfectly well in strict mode, why shouldn't I be able to turn strict on for my whole library? Do I just tell users that non-strict mode constitutes undefined behavior for this library, and refuse to fix any bugs that come up because of it? I'm sure I could find a way of detecting non-strict mode and throw a fatal, or force access through a facade/wrapper of some sort where I've turned on strict and made myself the caller. Isn't this equally unhelpful? The point is some people will want strict turned on, and they will find ways to force it on people. You're going to have to live with it, so just make it a possibility from the outset. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
On 17 February 2015 at 11:46, Alexander Lisachenko lisachenko...@gmail.com wrote: Hello, internals! I want to introduce a RFC for providing a userland API for accessing an Abstract Syntax Tree of the source code and to provide userland parser hooks for source code modification: https://wiki.php.net/rfc/parser-extension-api Thanks! Re: Userland representation of AST. I use Nikita's PHP-Parser for static analysis already, so my first reaction is that I like the idea of being able to obtain the canonical AST from the engine, that is automatically updated as new features are added. Does the AST provided by the internal parser provide all of the information required to be able to turn it back into source code? Re: Extending the parser from PHP userland. This I don't like so much. To be honest I hoped this would be an API to extend the parser from PHP extensions :) I think letting userland fiddle directly with the compilation process is just asking for trouble. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal
On 17 February 2015 at 17:35, Tim Bezhashvyly tim.bezhashv...@gmail.com wrote: Dear PHP internals, this is my first RFC proposal and I am not sure if in this email is supposed to contain all RFC details or just a brief idea .. which is to drop PHP constants in favour of “final immutable variables. I think we need some more details. Assuming since you mention final that your intent is to allow T_FINAL for class property definitions? Class constants have the ability to be referenced without instantiating the class as an object. What are the benefits of immutable properties over class constants? You certainly wont be able to _drop_ class constants as they are so widely used. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 18:33, François Laupretre wrote: What does this mean in your case ? Just that, as long as the feature is not available, your function won't have an explicit return type. Period. And, please, don't change false to 0 ;). I simply can't see the case for limited function type hints at all! I either already have clean defined data from the database, or I need to validate the data from users before using it. While validating I need to confirm constraints of data type so adding some extra wrapper that only does half the job just seems a pointless exercise. Annotating the correct data type would be of more use and I already have that in the docblock and my IDE produces those hints while I am writing the code - which it has done for many years. To my mind it IS in the IDE that much of this stuff which people keep saying is not 'runtime' should be managed, and anything that is not needed at 'runtime' should be removable but what is being added across several areas all seem to beadding the same things - partially - using different methods - without any obvious gain. Additionally I'm now passing data as an array as that was the 'best practice' a few years back so it is rare to be passing a single value anyway. -- 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] RFC Proposal
2015-02-17 20:35 GMT+03:00 Tim Bezhashvyly tim.bezhashv...@gmail.com: this is my first RFC proposal and I am not sure if in this email is supposed to contain all RFC details or just a brief idea .. which is to drop PHP constants in favour of “final immutable variables. Hello, Tim Recently, I asked this question on internals http://www.serverphorums.com/read.php?7,1123371 about immutable variables and objects. Please, continue it if you want to discuss it, this will keep the context of thread in one place. However, no need to drop constants, but only to add an additional behavior for objects and variables. Thanks!
RE: [PHP-DEV] Reviving scalar type hints
De : Lester Caine [mailto:les...@lsces.co.uk] On 17/02/15 18:33, François Laupretre wrote: What does this mean in your case ? Just that, as long as the feature is not available, your function won't have an explicit return type. Period. And, please, don't change false to 0 ;). I simply can't see the case for limited function type hints at all! I If you can't see it after so much was written on the subject, what can we do ? Do you imply that, if *you* cannot understand the need, it does not exist ? either already have clean defined data from the database, or I need to validate the data from users before using it. If that's your only data source, that's OK. I confirm you probably don't need type hinting. You probably even don't need functions, classes and the rest. A 50-line script should fit. While validating I need to confirm constraints of data type so adding some extra wrapper that only does half the job just seems a pointless exercise. The point of type hinting is not validating user input. Annotating the correct data type would be of more use and I already have that in the docblock and my IDE produces those hints while I am writing the code - which it has done for many years. That's different. There is overlapping there but the purpose is not the same. IDEs only can do a limited set of static analysis. As soon as you have indirect calls, IDE-based static analysis is down, let alone comment-stripped libraries and others. If you want more constraints on input and output, look at DbC (design by contract), as it can handle tests too slow to run in production. To my mind it IS in the IDE that much of this stuff which people keep saying is not 'runtime' should be managed, and anything that is not needed at 'runtime' should be removable but what is being added across several areas all seem to beadding the same things - partially - using different methods - without any obvious gain. Additionally I'm now passing data as an array as that was the 'best practice' a few years back so it is rare to be passing a single value anyway. IDEs are worthwile but not mandatory and runtime features have nothing to do with IDEs. Now, you were (aggressively) complaining about returning int or false. You were sure you had found the case that would prove all of this was ready for the bin. I took the time to explain. Then, you're complaining it's no use because you don't understand its purpose and because you chose to bundle your arguments in arrays... Unfortunately, I'm afraid I can't do more for you but what I generally hate : 'If we don't like it, don't use it'. I try to be kind with constructive posts but, here, I have better to do. François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
RE: [PHP-DEV] Annotations in PHP7
Hi Alexander, De : Alexander Lisachenko [mailto:lisachenko...@gmail.com] This RFC consists of two parts: parsing API and parser extension API. Last one can be rejected, however it can be perfectly connected with annotation RFC (if AST will be used as values) Parser extension API is great. Go on with it. I have a lot of uses in mind. As for annotations, general use-case is appreciated. This can be extended later in future versions of PHP. Therefore, annotation syntax should allow to define key and values. Value can be valid expression (AST? concrete node? compiled value?) or can recursively contain nested annotations. Can you give a use case for nested annotations ? I don't see what they can be needed for. Thanks François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
François, Doctrine relies on nested annotations for a variety of mapping information. One example: http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table []s, On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre franc...@php.net wrote: Hi Alexander, De : Alexander Lisachenko [mailto:lisachenko...@gmail.com] This RFC consists of two parts: parsing API and parser extension API. Last one can be rejected, however it can be perfectly connected with annotation RFC (if AST will be used as values) Parser extension API is great. Go on with it. I have a lot of uses in mind. As for annotations, general use-case is appreciated. This can be extended later in future versions of PHP. Therefore, annotation syntax should allow to define key and values. Value can be valid expression (AST? concrete node? compiled value?) or can recursively contain nested annotations. Can you give a use case for nested annotations ? I don't see what they can be needed for. Thanks François -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
[PHP-DEV] Scalar Type Hints v0.4
Based on conversations here and elsewhere on the internet, I'd like to put forward a rough gameplan for scalar types which I hope addresses most concerns. This is back-of-the-napkin and I'm not asking for a committed yes/no, just pre-rfc set of thoughts. Please don't get hung up on specific names, we can debate those in the coming week(s), I'm only looking for large architectural issues. 1) Introduce scalar types for primitives: bool, int, float, string, resource, object (we already have array) 1a) Introduce meta-types as pre-defined unions (we can add custom unions in a later rfc). A possible list may be as follows (again, we can argue what's in this list separately): * mixed: any type * scalar: (null|bool|int|float|string) * numeric (int|float|numeric-string) * stringish (string or object with __toString()) * boolish (like mixed, but coerces to bool) * etc... 2) Define a way to enable strict mode (we'll be weak by default). 2a) Userspace impact: Strict mode will throw a recoverable error on type mismatch. Weak mode will coerce the type according to conversion rules (See #3), throwing a recoverable error if coercion isn't possible. 2b) Internal impact: The same rules apply to internal functions as userspace functions HOWEVER, we use the types present in ZEND_ARG_INFO structures, not zpp. This has the net effect that every internal function remains effectively untyped unless specifically opted in by means of updating their arg info struct. In weak mode, internal functions coerce according to conversion rules. 3) Tighten up coersion rules for weak mode. i.e. 10 dogs for an int is a violation, but 10 is acceptable. 3a) Userspace impact: We're in a clean slate state, so this is safe from a BC perspective. 3b) Internal impact: Again, behavior remains unchanged unless the ZEND_ARG_INFO struct has been modified to add proper typehints. If typehints have been added, then the more aggressive coersion rules apply during typehint validation. I really want to underline the design expressed in #2b and #3b. zend_parse_parameters()'s types have been removed from the equation in this proposal. This means that, until someone audits a given function and makes the decision to give it a type, it will effectively behave as though always weak, regardless of the caller's flags. This enables us to give the same contractual behavior internally and externally, while still implicitly treating internal functions as a bit special for the purpose of moving forward. -Sara -- 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/16/2015 09:48 PM, Sara Golemon wrote:
Second, I should clarify that while the HHVM runtime performs
coersion, the hack type checker is strict. So my original statement
was inaccurate. As far as hack is concerned, it's simply strict.
Period.
With both the default (partial) type checking and strict enabled, my
number_format() example in Hack produces:
int(1000)
1,000
string(4) 1000
1,000
float(1000)
1,000
string(5) 1000
Warning: number_format() expects parameter 1 to be double, string given
string(5) 1000
1,000
string(9) 1000 dogs
Warning: number_format() expects parameter 1 to be double, string given
string(3) dog
Warning: number_format() expects parameter 1 to be double, string given
resource(4) of type (stream)
Warning: number_format() expects parameter 1 to be double, resource given
Basically it accepts, ints, floats and well-formed numeric strings and
the hh_client type checker is telling me I have No errors. So the only
difference between Hack's strict mode and the current coercive behaviour
in PHP is strings with trailing chars. The 1000 dogs case. 1000 as
well in my example, but that is the same case. Where in PHP you get a
notice but it still does the conversion and in Hack you get a warning
and the conversion isn't done. So even though Hack has both a partial
type checking mode and a strict mode, the decision was to still do
type coercion for the others. I kind of expected it to only accept a
float in full-on strict mode to mimic the no-compromise strictness
proposed in the RFC.
Also, looking through the code, I really don't see this simply strict
anywhere when it comes to calling internal functions. For example:
$a = [1,2,3,4,5];
print_r(array_reverse($a,0));
It doesn't complain that 0 is a string and not a boolean. It doesn't
even complain about dog there.
And the one everyone gets uppity about. bool-int conversion in
curl_setopt(). eg.
$ch = curl_init(https://74.125.28.104;);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
echo curl_exec($ch);
echo curl_error($ch);
PHP obviously converts true to 1 there which has been a problem because
what people really meant was to set it to 2. We spew a notice for this,
of course:
Notice: curl_setopt(): CURLOPT_SSL_VERIFYHOST with value 1 is deprecated
and will be removed as of libcurl 7.28.1. It is recommended to use value
2 instead in ...
In Hack it appears that true is also converted to 1 in ?hh // strict
mode and no notice appears and the hh_client type checker doesn't
complain. If instead of true I pass in an array of strings, it still
converts it to 1 even though the type is blatantly wrong. It looks like
it was kept quite loose to match PHP and not cause too much legacy code
to break. In this particular case it is pretty dangerous to be
completely silent about it though since it actually means no host
verification is getting done. The output when properly set to 2 from
both PHP and Hack is:
SSL: certificate subject name 'www.google.com' does not match target
host name '74.125.28.104'
Please correct me here if I somehow ran these incorrectly. I did put
some deliberate type errors into my userspace code and hh_client caught
those nicely, so it seems like it was working, but it didn't catch
anything when it came to calling the internal API functions.
eg.
?hh // strict
function test() : int {
$ch = curl_init(https://74.125.28.104;);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, [I have no idea what I am
doing]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
echo curl_exec($ch);
echo curl_error($ch);
return beer;
}
hh_client reports:
/home/rasmus/test/a.php:8:12,17: Invalid return type (Typing[4110])
/home/rasmus/test/a.php:2:19,21: This is an int
/home/rasmus/test/a.php:8:12,17: It is incompatible with a string
When I change return beer to return 1 hh_client is happy.
So, you keep asking what I would support. I would like to see an RFC
along the following lines:
1. Tighten up the type coercion for the 1000 dogs case although we
have to look at whether there is a problem with some database APIs
returning space-padded fields so 1000 would now break.
Hopefully that is fringe enough to not break the world.
2a. In strict mode, tone down the strictness and allow non-lossy
coercion including int-float. And yes, I know in really edge cases
that isn't technically non-lossy, but for all practical purposes it
is.
or
2b. A much more flexible system for specifying multiple types. I should
be able to say that my function takes something that looks like a
number if I choose and still take advantage of stricter typing for
other parameters.
3. Don't turn on crazy-strict mode for internal functions that weren't
designed for that. Instead provide the same ability as userspace gets
for developers to gradually design their APIs to be stricter if they
so desire allowing both Hack and PHP
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 21:28, François Laupretre wrote: De : Lester Caine [mailto:les...@lsces.co.uk] On 17/02/15 18:33, François Laupretre wrote: What does this mean in your case ? Just that, as long as the feature is not available, your function won't have an explicit return type. Period. And, please, don't change false to 0 ;). I simply can't see the case for limited function type hints at all! I If you can't see it after so much was written on the subject, what can we do ? Do you imply that, if *you* cannot understand the need, it does not exist ? Since it has already been said that what is proposed is 'just a start' then the missing bits may get added later - and if it is anything like PDO will it arrive before PHP10 :) either already have clean defined data from the database, or I need to validate the data from users before using it. If that's your only data source, that's OK. I confirm you probably don't need type hinting. You probably even don't need functions, classes and the rest. A 50-line script should fit. http://hg.lsces.org.uk/bw/bitweaver/ is a little more than 50 lines ... lsces.org.uk/bitweaverdocsPHP/index.html hasn't been updated since we lost the original phpDocumentor but now I do need to try and get a new version run including all the e_strict stuff that hs been reworked in the last 5 years. While validating I need to confirm constraints of data type so adding some extra wrapper that only does half the job just seems a pointless exercise. The point of type hinting is not validating user input. Again limited application of a useful function. Strict scalar type hints are only there to give an error when something is wrong. How is that not doing validation? If you HAVE validated the data then where do you need the hint other than reminding you just what you need to validate to? And if you have validated then one can pass a value rather than a string anyway? Annotating the correct data type would be of more use and I already have that in the docblock and my IDE produces those hints while I am writing the code - which it has done for many years. That's different. There is overlapping there but the purpose is not the same. IDEs only can do a limited set of static analysis. As soon as you have indirect calls, IDE-based static analysis is down, let alone comment-stripped libraries and others. If you want more constraints on input and output, look at DbC (design by contract), as it can handle tests too slow to run in production. I would not even bother trying to understand the PHP code base without a decent IDE, and Eclipse provides that. PHP files live next to C/C++ and other file formats, so the one set of tools allow everything to work productively. I don't find any problem seeing indirect call annotation and although PHPeclipse is now struggling with new things ( like dropping the ? in the MIDDLE of phpt files :( ) it has done the jobs that most of this extra infrastructure is trying to duplicate for a lot of the life of PHP5. To my mind it IS in the IDE that much of this stuff which people keep saying is not 'runtime' should be managed, and anything that is not needed at 'runtime' should be removable but what is being added across several areas all seem to beadding the same things - partially - using different methods - without any obvious gain. Additionally I'm now passing data as an array as that was the 'best practice' a few years back so it is rare to be passing a single value anyway. IDEs are worthwile but not mandatory and runtime features have nothing to do with IDEs. Now, you were (aggressively) complaining about returning int or false. You were sure you had found the case that would prove all of this was ready for the bin. I took the time to explain. Then, you're complaining it's no use because you don't understand its purpose and because you chose to bundle your arguments in arrays... Flagging that a value HAS to be an integer is fine, and hopefully the move to make that an unconstrained object rather than a simple register value has passed, but even here the next step is rather than hiding the fact that in many cases there IS a limit, the move to 64bit values in parallel with 32bit ones needs much better management and it's the total disregard for that which is my problem. 'PHP has not worried about that in the past' neatly sidesteps the fact that we USED 32bit builds of PHP5 to avoid the problems, but nowadays we have legacy systems that are still locked to 32bit values while new systems are running 64bit and so now it IS something to at least take some interest in. int4 and int8 are equally as important as int(unlimited) and while ignoring 32bit builds may be practical for some, it still has a place in many areas. Unfortunately, I'm afraid I can't do more for you but what I generally hate : 'If we don't like it, don't use it'. I try to be kind with constructive posts but, here, I have better to do.
[PHP-DEV] Compile problems - Was Switch jumptable optimization
On 16/02/15 23:55, Rasmus Lerdorf wrote: this doesn't really look related to my patch. Did you do something wrong when cloning my branch? Or forget a make clean or similar? Locally it works for me and echoes 1 as expected. Ah, looks like you are right. A full distclean cleared it up. I had just done a distclean, but I had built once before applying your patch. Crappy Makefile deps.. It seems not even running distclean clears down everything that needs removing for some of the changes currently going through. ./vcsclean does not work for me since I'm running Hg locally, but an hg purge /all did clean everything up, so obviously there is something in the .gitignore file that should also be in the distclean list? Or should distclean actually be using .gitignore as it's 'clean' list? Anyway I now have a working build of PHP7 again having wasted a couple more days trying to track down what was wrong. -- 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] [RFC] Exceptions in the engine
Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com: On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Thanks, Nikita [1]: https://wiki.php.net/rfc/engine_exceptions Feature freeze is not so far away now, so I'd like to bring this RFC up again and proceed to voting shortly. There are two primary open questions: * Subclassing: Should there be more specific subclasses of EngineException for particular errors? * Superclassing: Should EngineException inherit from Exception (and as such be subject to catch(Exception)) or should we introduce some kind of special super-class that is not caught by default (like Catchable/Throwable)? I don't think we can implement a high-quality subclassing scheme in a timeframe for PHP 7, as such I would suggest to postpone this (if we actually want to do it) to a later point in time. We can introduce subclasses without BC issues in a minor version. The question of whether EngineException should inherit from Exception is something we do have to consider now. Personally I prefer not introducing any special exception types that aren't caught by default. I think that would only make sense for errors that could occur literally everywhere (like memory limit or timeout), but these are not handled by this RFC for technical reasons. If someone has a strong opinion on this, I might make it a voting option. Commentary on these, and also any other relevant points is very welcome! Thanks, Nikita PS: The patch attached to the RFC is very outdated. I plan to only update it to current master once the RFC passes (if it does), as I already had to practically rewrite it a few times. Hey, For subclassing I totally agree that we should postpone this (if we want this at all). I think EngineException should inherit from Exception. You usually only catch Exception in catch-all handlers to display, log etc. the backtraces. In all these cases, you're very likely to want to catch the EngineException too, without a second catch block where the catch body is duplicated. I can't really think of a catch-all block where you'd explicitly don't want to handle EngineException. And if it'd really be the case, you still can do an instanceof check and rethrow if needed... Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact would
it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE 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.
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.
That has absolutely nothing to do with OO vs procedural code, though. 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?
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Am 17.02.2015 um 11:21 schrieb Benjamin Eberlei kont...@beberlei.de: On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand bobw...@hotmail.com mailto:bobw...@hotmail.com wrote: Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com mailto:nikita@gmail.com: On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com mailto:nikita@gmail.com wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Thanks, Nikita [1]: https://wiki.php.net/rfc/engine_exceptions https://wiki.php.net/rfc/engine_exceptions Feature freeze is not so far away now, so I'd like to bring this RFC up again and proceed to voting shortly. There are two primary open questions: * Subclassing: Should there be more specific subclasses of EngineException for particular errors? * Superclassing: Should EngineException inherit from Exception (and as such be subject to catch(Exception)) or should we introduce some kind of special super-class that is not caught by default (like Catchable/Throwable)? I don't think we can implement a high-quality subclassing scheme in a timeframe for PHP 7, as such I would suggest to postpone this (if we actually want to do it) to a later point in time. We can introduce subclasses without BC issues in a minor version. The question of whether EngineException should inherit from Exception is something we do have to consider now. Personally I prefer not introducing any special exception types that aren't caught by default. I think that would only make sense for errors that could occur literally everywhere (like memory limit or timeout), but these are not handled by this RFC for technical reasons. If someone has a strong opinion on this, I might make it a voting option. Commentary on these, and also any other relevant points is very welcome! Thanks, Nikita PS: The patch attached to the RFC is very outdated. I plan to only update it to current master once the RFC passes (if it does), as I already had to practically rewrite it a few times. Hey, For subclassing I totally agree that we should postpone this (if we want this at all). I think EngineException should inherit from Exception. You usually only catch Exception in catch-all handlers to display, log etc. the backtraces. In all these cases, you're very likely to want to catch the EngineException too, without a second catch block where the catch body is duplicated. I can't really think of a catch-all block where you'd explicitly don't want to handle EngineException. And if it'd really be the case, you still can do an instanceof check and rethrow if needed... I think that would be a huge BC break. I see a lot of code just catching \Exception at various customers and opensource projects. EngineException should not be a child of Exception. Thanks, Bob No, it isn't a BC break. It would only affect broken things, which generate fatals as of now. Working applications are not affected and that way it does not break BC. So, I don't see any harm here in superclassing EngineException. Bob
[PHP-DEV] [RFC][Discussion] Parser extension API
Hello, internals! I want to introduce a RFC for providing a userland API for accessing an Abstract Syntax Tree of the source code and to provide userland parser hooks for source code modification: https://wiki.php.net/rfc/parser-extension-api Thanks!
Re: [PHP-DEV] Reviving scalar type hints
On Tue, Feb 17, 2015 at 9:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/16/2015 09:48 PM, Sara Golemon wrote:
Second, I should clarify that while the HHVM runtime performs
coersion, the hack type checker is strict. So my original statement
was inaccurate. As far as hack is concerned, it's simply strict.
Period.
With both the default (partial) type checking and strict enabled, my
number_format() example in Hack produces:
int(1000)
1,000
string(4) 1000
1,000
float(1000)
1,000
string(5) 1000
Warning: number_format() expects parameter 1 to be double, string given
string(5) 1000
1,000
string(9) 1000 dogs
Warning: number_format() expects parameter 1 to be double, string given
string(3) dog
Warning: number_format() expects parameter 1 to be double, string given
resource(4) of type (stream)
Warning: number_format() expects parameter 1 to be double, resource given
Basically it accepts, ints, floats and well-formed numeric strings and
the hh_client type checker is telling me I have No errors. So the only
difference between Hack's strict mode and the current coercive behaviour
in PHP is strings with trailing chars. The 1000 dogs case. 1000 as
well in my example, but that is the same case. Where in PHP you get a
notice but it still does the conversion and in Hack you get a warning
and the conversion isn't done. So even though Hack has both a partial
type checking mode and a strict mode, the decision was to still do
type coercion for the others. I kind of expected it to only accept a
float in full-on strict mode to mimic the no-compromise strictness
proposed in the RFC.
Also, looking through the code, I really don't see this simply strict
anywhere when it comes to calling internal functions. For example:
$a = [1,2,3,4,5];
print_r(array_reverse($a,0));
It doesn't complain that 0 is a string and not a boolean. It doesn't
even complain about dog there.
And the one everyone gets uppity about. bool-int conversion in
curl_setopt(). eg.
$ch = curl_init(https://74.125.28.104;);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
echo curl_exec($ch);
echo curl_error($ch);
PHP obviously converts true to 1 there which has been a problem because
what people really meant was to set it to 2. We spew a notice for this,
of course:
Notice: curl_setopt(): CURLOPT_SSL_VERIFYHOST with value 1 is deprecated
and will be removed as of libcurl 7.28.1. It is recommended to use value
2 instead in ...
I think curl_setopt is a misleading example in the typehinting discussion,
because
this kind of API does not benefit from it. The third argument depends
on the second argument and requires a generic type in code:
curl_setopt(resource $ch, int $option, mixed $data);
It won't be possible to change this (or any similar API) with strict type
hints.
The code to convert a boolean $data to integer in the VERIFYPEER case is
manually
implemented and therefore subject to the implementors design decisions.
In Hack it appears that true is also converted to 1 in ?hh // strict
mode and no notice appears and the hh_client type checker doesn't
complain. If instead of true I pass in an array of strings, it still
converts it to 1 even though the type is blatantly wrong. It looks like
it was kept quite loose to match PHP and not cause too much legacy code
to break. In this particular case it is pretty dangerous to be
completely silent about it though since it actually means no host
verification is getting done. The output when properly set to 2 from
both PHP and Hack is:
SSL: certificate subject name 'www.google.com' does not match target
host name '74.125.28.104'
Please correct me here if I somehow ran these incorrectly. I did put
some deliberate type errors into my userspace code and hh_client caught
those nicely, so it seems like it was working, but it didn't catch
anything when it came to calling the internal API functions.
eg.
?hh // strict
function test() : int {
$ch = curl_init(https://74.125.28.104;);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, [I have no idea what I am
doing]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
echo curl_exec($ch);
echo curl_error($ch);
return beer;
}
hh_client reports:
/home/rasmus/test/a.php:8:12,17: Invalid return type (Typing[4110])
/home/rasmus/test/a.php:2:19,21: This is an int
/home/rasmus/test/a.php:8:12,17: It is incompatible with a string
When I change return beer to return 1 hh_client is happy.
So, you keep asking what I would support. I would like to see an RFC
along the following lines:
1. Tighten up the type coercion for the 1000 dogs case although we
have to look at whether there is a problem with some database APIs
returning space-padded fields so 1000 would now break.
Hopefully that is fringe enough to not break the world.
2a. In strict mode, tone down the
Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 01:11 AM, Benjamin Eberlei wrote:
I think curl_setopt is a misleading example in the typehinting
discussion, because
this kind of API does not benefit from it. The third argument depends
on the second argument and requires a generic type in code:
curl_setopt(resource $ch, int $option, mixed $data);
It won't be possible to change this (or any similar API) with strict
type hints.
The code to convert a boolean $data to integer in the VERIFYPEER case is
manually
implemented and therefore subject to the implementors design decisions.
Sure, I realize this, but it is the bool-int coercion example that is
always brought up. A static analysis type checker would have trouble
catching this, but both PHP and Hack apply that coercion at runtime:
case CURLOPT_SSL_VERIFYHOST:
if(Z_BVAL_PP(zvalue) == 1) {
The runtime could say, hey, I am in strict mode here and you are passing
me an array of strings which I am coercing to a boolean. Not cool.
-Rasmus
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Reviving scalar type hints
2015-02-17 0:58 GMT+01:00 Sara Golemon poll...@php.net: On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net wrote: Straw poll: 1) ?php strict; 2) ?php-strict 3) use strict; (psuedo-namespace) 4) ?php // strict (I don't actually like HHVM's style, but if you do...) 5) declare(strict=true); (As a top-level declare only) 6) declare(strict=true); (exactly as in v0.3 -- maybe you liked it) 7) your write-in vote here (i changed double 3 voting option in quote) +1 for all which can only be defined on the first line so: 1,2, 4, 5
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand bobw...@hotmail.com wrote: Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com: On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Thanks, Nikita [1]: https://wiki.php.net/rfc/engine_exceptions Feature freeze is not so far away now, so I'd like to bring this RFC up again and proceed to voting shortly. There are two primary open questions: * Subclassing: Should there be more specific subclasses of EngineException for particular errors? * Superclassing: Should EngineException inherit from Exception (and as such be subject to catch(Exception)) or should we introduce some kind of special super-class that is not caught by default (like Catchable/Throwable)? I don't think we can implement a high-quality subclassing scheme in a timeframe for PHP 7, as such I would suggest to postpone this (if we actually want to do it) to a later point in time. We can introduce subclasses without BC issues in a minor version. The question of whether EngineException should inherit from Exception is something we do have to consider now. Personally I prefer not introducing any special exception types that aren't caught by default. I think that would only make sense for errors that could occur literally everywhere (like memory limit or timeout), but these are not handled by this RFC for technical reasons. If someone has a strong opinion on this, I might make it a voting option. Commentary on these, and also any other relevant points is very welcome! Thanks, Nikita PS: The patch attached to the RFC is very outdated. I plan to only update it to current master once the RFC passes (if it does), as I already had to practically rewrite it a few times. Hey, For subclassing I totally agree that we should postpone this (if we want this at all). I think EngineException should inherit from Exception. You usually only catch Exception in catch-all handlers to display, log etc. the backtraces. In all these cases, you're very likely to want to catch the EngineException too, without a second catch block where the catch body is duplicated. I can't really think of a catch-all block where you'd explicitly don't want to handle EngineException. And if it'd really be the case, you still can do an instanceof check and rethrow if needed... I think that would be a huge BC break. I see a lot of code just catching \Exception at various customers and opensource projects. EngineException should not be a child of Exception. Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 17/02/15 06:20, Sara Golemon wrote: * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as standard (like numeric), others user-definable) And also ... int4, int8 and similar for correctly constrained values. In an ideal world the whole SQL standard types would be available, but this at least would allow int to become an unconstrained object if people want that. It's the whole we can fix it later that I don't like ... especially when other votes are changing the goal posts in parallel. -- 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] [RFC][Discussion] Parser extension API
2015-02-17 15:06 GMT+03:00 Leigh lei...@gmail.com: Does the AST provided by the internal parser provide all of the information required to be able to turn it back into source code? Yes, this should be possible, via zend_emit_op*() and zend_compile*() 2015-02-17 15:06 GMT+03:00 Leigh lei...@gmail.com: Re: Extending the parser from PHP userland. This I don't like so much. To be honest I hoped this would be an API to extend the parser from PHP extensions :) I think letting userland fiddle directly with the compilation process is just asking for trouble. Expected reaction ) However, it would be nice to have such API on userland too (on engine level this can be a hook too). This will give an instrument for building custom things on user side, but will keep PHP engine clear from a lot of stuff, which can be implemented by users. Nice example is Design-By-Contract validation, it can be easily done via parser hooks.
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
2015-02-17 15:09 GMT+03:00 Benjamin Eberlei kont...@beberlei.de: The visitor API is the essential part here and you left it out. Yes, I decided not to put Visitor in the RFC (this was added as open question to the RFC). But this part can be discussed in the case of general acceptance. 2015-02-17 15:09 GMT+03:00 Benjamin Eberlei kont...@beberlei.de: How does this work with Engine Extensions, are they considered for all require/include's *after* the registrtion? How does this work with opcache? Yes, parser extensions will be called for all require/include/evals after registration. This part is transparent for opcache, because opcache just stores an opcodes for the file. AST is parsed only once for each file, then hooks can transform the AST and after that compiler will produce a final opcodes that can be stored for that file in the opcache. So, I expect no impact on opcache logic.
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
2015-02-17 15:29 GMT+03:00 Benjamin Eberlei kont...@beberlei.de: Well not really, depending on the path towards a require a parser extension is already registered or not. Or you have conditional registration of extensions. So you could load a file with an extension registered, but it still serves the old opcodes for that file. Technically, this will be possible, however, Parser Extensions should be registered ASAP during bootstrap process, near spl_autoload_register(), stream_wrapper_register(), stream_filter_register(), etc.. So, no conditional code hooks should be used for that. But this can be the consistent with stream wrappers, filters and autoloaders. Developer can decide what he need to enable some features. One more possible way for this RFC is to remove these register/unregister methods from the `Php\Parser\Engine` class and add an option to the php.ini with list of classes to load. This option can be adjusted then per project/directory. Is this more suitable? Thanks!
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
On 17 February 2015 at 12:22, Alexander Lisachenko lisachenko...@gmail.com wrote: Yes, parser extensions will be called for all require/include/evals after registration. This part is transparent for opcache, because opcache just stores an opcodes for the file. AST is parsed only once for each file, then hooks can transform the AST and after that compiler will produce a final opcodes that can be stored for that file in the opcache. So, I expect no impact on opcache logic. So: Internal Parse AST - Extension Parse AST - Generate OpCodes - OpCache? So if the parser extension does anything dynamic, then OpCache will have the wrong version cached. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Mon, 16 Feb 2015, Sara Golemon wrote: On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net wrote: Once again, anyone can take over version 0.3, if it is so great. Why don't you do it ? I will play the game, stop working on my proposal, and vote 'yes' again. But don't ask me to do it in your place. If nobody else does it, I will. Please do! I think Andrea's 0.3 proposal was extremely well balanced, served everyone's needs whether they would admit it or not, and who's only failing (subjectively termed) was the use of declare(). I think declare() is fine and not nearly as ugly as some have slandered it to be, but I'm willing to read the winds and modify it for v0.4. Straw poll: These two are my preference: 3) use strict; (psuedo-namespace) 4) declare(strict=true); (As a top-level declare only) cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
On Tue, Feb 17, 2015 at 12:46 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: Hello, internals! I want to introduce a RFC for providing a userland API for accessing an Abstract Syntax Tree of the source code and to provide userland parser hooks for source code modification: https://wiki.php.net/rfc/parser-extension-api 1. The visitor API is the essential part here and you left it out. 2. How does this work with Engine Extensions, are they considered for all require/include's *after* the registrtion? How does this work with opcache? Thanks!
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
On Tue, Feb 17, 2015 at 1:22 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: 2015-02-17 15:09 GMT+03:00 Benjamin Eberlei kont...@beberlei.de: The visitor API is the essential part here and you left it out. Yes, I decided not to put Visitor in the RFC (this was added as open question to the RFC). But this part can be discussed in the case of general acceptance. 2015-02-17 15:09 GMT+03:00 Benjamin Eberlei kont...@beberlei.de: How does this work with Engine Extensions, are they considered for all require/include's *after* the registrtion? How does this work with opcache? Yes, parser extensions will be called for all require/include/evals after registration. This part is transparent for opcache, because opcache just stores an opcodes for the file. AST is parsed only once for each file, then hooks can transform the AST and after that compiler will produce a final opcodes that can be stored for that file in the opcache. So, I expect no impact on opcache logic. Well not really, depending on the path towards a require a parser extension is already registered or not. Or you have conditional registration of extensions. So you could load a file with an extension registered, but it still serves the old opcodes for that file.
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
2015-02-17 15:48 GMT+03:00 Leigh lei...@gmail.com: So: Internal Parse AST - Extension Parse AST - Generate OpCodes - OpCache? Yes, it's correct flow. 2015-02-17 15:48 GMT+03:00 Leigh lei...@gmail.com: So if the parser extension does anything dynamic, then OpCache will have the wrong version cached. This restriction is intended by design, no dynamic changes are allowed. However, if you need, then you can disable an opcode cacher and do anything you want. Your example is actual for production mode of PHP too, when opcache.validate_timestamps=0 or apc.stat=off. Parsing will be performed only once, then you need to clear cache manually to reload changes from the file system. So, parser extension works transparently and used only when needed to process an AST.
RE: [PHP-DEV] Reviving scalar type hints
Hi Sara,
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara
Golemon
So, if you'll permit me to summarize your message. The following
would be palatable to you?
* Lossless coercion. This would sit somewhere between strict types
and weak types as lossy conversions (object-__toString() for objects
passed where string expected, any-bool) would be disallowed, but
lossless conversions (numeric strings to number types, int to float,
whole floats to ints, numbers to strings -- But no implicit
conversions to bools, no non-numeric strings to numerics, etc...)
1. it must be implemented as a modification to zpp conversion rules. IMHO, a
third mode would be the worst thing to do.
2. It is not not about being lossless or not. People expect bool - int to be
disabled, for example, and it is not lossless.
3. It is more a question of finding a consensus about conversions which don't
make sense, and disabling them. Examples include bool conversion to any other
type and, of course, disabling trailing chars in numeric strings.
4. Once this is done, 99% of strict type proponents already said they would be
OK with the so-called (not so) weak mode, making it possible to get rid of this
far from perfect two-mode mechanism (actually, this two-mode approach more and
more reminds me a great idea about bringing transparent Unicode support in PHP).
If future development tools require more precise types (and they probably
will), the mechanism can be extended with new keywords, but the idea is never
using the same keyword for different ways to check a zval. New keywords would
be defined at the zpp level, keeping internal and userspace features in sync.
Would you agree proposing this as an option in 0.4 ? Actually, I will write it
as a separate RFC as modifying zpp conversion rules has impacts well beyond
type hinting. Then, type hinting RFCs can reference it.
* Exclude internal functions from the strict switch. (Perhaps have a
separate switch for internal functions at a later date)
This would make the feature inconsistent from an end user's pov.
If a user enables strict mode, he assumes strict checks for every function he
calls. *We* know that userspace and internal functions use different
mechanisms, but the end user doesn't have to know. From his pov, a function is
a function. If the documentation states that the function he's calling in
strict mode accepts int, he will expect int to be checked in strict mode. We
cannot say 'Oh, wait, it's an internal function, the rules are not the same'.
The distinction between internal and userpace functions is irrelevant for him
and has to remain so.
So, from all these arguments, I now think that strict types, as defined in 0.3,
are not the best solution.
With option to introduce features such as the following at a later date:
* Union types (e.g. function foo((int | float) $value): (bool | string) { ...
})
* Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as
standard (like numeric), others user-definable)
As I told Zeev, union types can be kept for the future if we don't go the
nullable road, as it would be too confusing making 'string|null' and '?string'
synonyms.
The question of null is not so simple. IMO, it should be left for a future
discussion about union types. Anyway, once people get used to scalar hinting,
the need for union types will arise quickly.
Regards
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
