Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 11:05 AM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Wed, Feb 18, 2015 at 8:02 AM, Dmitry Stogov dmi...@zend.com wrote:
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.
nested can be done in any way, its a statement so the following would work:
orm(new JoinTable(['joinColumns' = [new JoinColumn('id', 'other_id')]]))
You might need to improve this by defining functions, so that new
JoinTable becomes just JoinTable, but in any case we will find a way to
make it work in Doctrine.
Are you (and Doctrine team) interested in this annotation idea?
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] Annotations in PHP7
On Wed, Feb 18, 2015 at 8:02 AM, Dmitry Stogov dmi...@zend.com wrote:
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.
nested can be done in any way, its a statement so the following would work:
orm(new JoinTable(['joinColumns' = [new JoinColumn('id', 'other_id')]]))
You might need to improve this by defining functions, so that new
JoinTable becomes just JoinTable, but in any case we will find a way to
make it work in Doctrine.
[]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] Compile problems - Was Switch jumptable optimization
Am 17.02.2015 um 10:51 schrieb Lester Caine: It seems not even running distclean clears down everything that needs removing for some of the changes currently going through. ./vcsclean I stopped using distclean / vcsclean a while ago. git clean -xdf does the trick for me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
Hi!
So let's talk compromise.
Would leaving internal functions out of the picture at this stage
change you mind? This is effectively what Hack does, internal
functions are explicitly marked as coercible.
For me, the option that makes users remember which functions are
internal and which are not, because they work radically different (and I
don't mean in some small detail, I mean up to a complete failure if I
get it wrong) is not something I'd really like.
Would a tri-state option make sense? ('weak-all',
'strict-user/weak-internal', 'strict-all')
How do we get from here to something you would like?
Two semantics in the same language are bad enough. Three, IMHO, is just
a no go, dealing with code having three different semantics would be
completely impossible.
--
Stas Malyshev
smalys...@gmail.com
--
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 11:59 AM, Derick Rethans der...@php.net wrote: On Tue, 17 Feb 2015, Dmitry Stogov wrote: On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans der...@php.net wrote: On Mon, 16 Feb 2015, Dmitry Stogov 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 Why didn't you pick the same syntax as hack? It's not smart enough to be used for DbC, AOT and many other features (we are going to capture AST). I realize that, but: optimization_level(2) could easily look like: optimization_level(2) The latter syntax … is what Hack does, but you picked … - which makes it both the same as HTML/XML tags *and* different from Hack. The … syntax also gets in the way of XHP (https://github.com/facebookarchive/xhp-php5-extension) cheers, Derick I don't care about decorators. If we come to vote I may add a separate question about vs Thanks. Dmitry.
Re: [PHP-DEV] Scalar Type Hints v0.4
Hi, On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski z...@zend.com wrote: -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? I too am curious about the potential issue with 123 to 123 specifically, although it could be seen as a subset of another problem that is solved with strict hints - numeric-character string identifiers being erroneously treated as integers. That is especially bad when such identifiers are in fact generated as integers first so that they are incremental, but the program/database/business logic requires them to be fixed-length strings and/or in hexadecimal format. In such cases, even silently discarding leading zeros can prove to be problematic, while in the case of hexadecimal representations you'd need more than 10 data samples to notice the problem if you don't use a strict hint. Obviously, that would be solved with automated testing, but unfortunately even code with high test coverage % often lacks depth in its test cases. I believe reduced amount of necessary unit tests was already brought up as an advantage of strict type hints, so I'm just explaining one such use case in detail here. Cheers, Andrey. -- 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 17/02/15 23:03, Sara Golemon wrote: 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) Hold on, usually, type checking functions don't identify NULL as scalar. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compile problems - Was Switch jumptable optimization
On 18/02/15 08:02, Sebastian Bergmann wrote: It seems not even running distclean clears down everything that needs removing for some of the changes currently going through. ./vcsclean I stopped using distclean / vcsclean a while ago. git clean -xdf does the trick for me. hg purge /all needed a little help to hide the bits that I need for thg and eclipse, but I seem to have that under control now. So it's just a right click function in thg. All that remains is adding back in extensions like imagick which I'd like in the ext folder but which git/hg want from a different repo. Ideally ext would just be a list of sub-repo's one can switch on and off rather than having to list each in the ./configure string. I'm using a local process via hg to merge the different git elements so that the IDE sees all the cross references in the one code tree. On that side, I don't enable the mysql stuff normally and while mysqlnd is compiling happily as a shared extension it looks like I can't load it as it is not actually a valid extension? Is that a bug or is the fact it's allowed to select 'shared' in ./configure the bug? -- 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
Nikita Popov wrote on 18/02/2015 00:35: 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 actually rather like this idea - it allows internal functions to gradually introduce scalar type hints just as userland code will gradually introduce them, rather than assuming a new meaning of existing metadata. It gives a chance to look, for each function, what hints make sense, separate from the technical requirements of translating to a strongly typed set of C variables, which is the main role of ZPP. Note that, however natural it may seem to core/extension devs, the workings of ZPP are not at all obvious to users, so the more similarities between internal and user-defined type hints, the better. 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. I see it working well if a large batch of uncontroversial functions have type hints mechanically added straight away, and then more complex cases are looked at in detail and discussed via pull requests or similar. What you have identified there is a danger to be watched out for, certainly, but it is not an inevitable outcome, if we come up with a decent set of guidelines of how the feature should be used. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Michael Wallner wrote on 18/02/2015 11:19: On 17/02/15 23:03, Sara Golemon wrote: 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) Hold on, usually, type checking functions don't identify NULL as scalar. No need for anyone to hold on; as it says in the section you've quoted we can argue what's in this list separately. Sara's after reactions to the principle of having meta-types/unions in general, not their definitions, right now. Regards, -- Rowan Collins [IMSoP] -- 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 18/02/15 09:14, Andrey Andreev wrote: That is especially bad when such identifiers are in fact generated as integers first so that they are incremental, but the program/database/business logic requires them to be fixed-length strings and/or in hexadecimal format. In such cases, even silently discarding leading zeros can prove to be problematic, while in the case of hexadecimal representations you'd need more than 10 data samples to notice the problem if you don't use a strict hint. Obviously, that would be solved with automated testing, but unfortunately even code with high test coverage % often lacks depth in its test cases. Octal is something that can often be miss converted since it IS the same as an integer with only a '0' in front in PHP. But that is not something that can be fixed with the current proposals? Again we have to ensure that the pre-processing takes care of the problem and how would static analysis even know there was a problem? A type hint following the SQL standards would be more helpful than the javascript approach of giving an error in strict mode. -- 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
On 18 Feb 2015 13:53, Tony Marston tonymars...@hotmail.com wrote: Could it be restricted to the current scope? In your example the call to fopen() exists in the load_data() function and is not in a try ... catch block within *that* function, so the fact that the call to load_data() is within a try ... catch block should be irrelevant as it is in a different scope. Hi Tony, This sounds very hacky. If you want exceptions with file/stream functions I suggest you to find some open library out there that can handle your user case or you can use SplFileObject.
Re: [PHP-DEV] Scalar Type Hints v0.4
On 18/02/15 12:31, Rowan Collins wrote: Michael Wallner wrote on 18/02/2015 11:19: On 17/02/15 23:03, Sara Golemon wrote: 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) Hold on, usually, type checking functions don't identify NULL as scalar. No need for anyone to hold on; as it says in the section you've quoted we can argue what's in this list separately. Sara's after reactions to the principle of having meta-types/unions in general, not their definitions, right now. Did you already incorporate strict mode yourself? SCNR I'm not a native speaker, so hold on might mean something different to you than to me. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Tue, 17 Feb 2015, Dmitry Stogov wrote: On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans der...@php.net wrote: On Mon, 16 Feb 2015, Dmitry Stogov 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 Why didn't you pick the same syntax as hack? It's not smart enough to be used for DbC, AOT and many other features (we are going to capture AST). I realize that, but: optimization_level(2) could easily look like: optimization_level(2) The latter syntax … is what Hack does, but you picked … - which makes it both the same as HTML/XML tags *and* different from Hack. The … syntax also gets in the way of XHP (https://github.com/facebookarchive/xhp-php5-extension) cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Hi,
On Wed, Feb 18, 2015 at 11:54 AM, Lester Caine les...@lsces.co.uk wrote:
On 18/02/15 09:14, Andrey Andreev wrote:
That is especially bad when such identifiers are in fact generated as
integers first so that they are incremental, but the
program/database/business logic requires them to be fixed-length
strings and/or in hexadecimal format. In such cases, even silently
discarding leading zeros can prove to be problematic, while in the
case of hexadecimal representations you'd need more than 10 data
samples to notice the problem if you don't use a strict hint.
Obviously, that would be solved with automated testing, but
unfortunately even code with high test coverage % often lacks depth in
its test cases.
Octal is something that can often be miss converted since it IS the same
as an integer with only a '0' in front in PHP. But that is not something
that can be fixed with the current proposals? Again we have to ensure
that the pre-processing takes care of the problem and how would static
analysis even know there was a problem? A type hint following the SQL
standards would be more helpful than the javascript approach of giving
an error in strict mode.
I'm not talking about octal, and nobody's talking about SQL here.
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and
on the very first if it was a strict hint:
for ($i = 0; $i 11; $i++)
{
foo(base_convert($i, 10, 16));
}
And when I said leading zeros, I was talking about fixed-length string
identifiers such as '001', '002', etc. where you may *unintentionally*
pass such a value to a function that deals with ... quantities, for
example. A strict hint in that case would immediately catch this
logical error while a weak hint would silently ignore the leading
zeros and will happily treat the value as an integer. Again, the
precondition here is that it's not an integer value that happens to be
stored as a string, but a non-integer value that just looks like an
integer.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal
Dear internals, my RFC was not about dropping just class constants but constants in general. Now I realise that you are not ready for this and most likely will never be. Thus I’m withdrawing my proposal. Regards, Tim On 18 Feb 2015, at 06:59, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 8:35 PM, Tim Bezhashvyly tim.bezhashv...@gmail.com mailto: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 http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact would
it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it could be a permissions error, for example). Is there any plan to
convert procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors. Changing
any
other error types to exceptions would be a significant
backwards-compatibility break.
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,
Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within *that* function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Scalar Type Hints v0.4
-Ursprüngliche Nachricht-
Von: Zeev Suraski [mailto:z...@zend.com]
Gesendet: Mittwoch, 18. Februar 2015 08:00
An: Nikita Popov; Rasmus Lerdorf
Cc: Sara Golemon; PHP internals
Betreff: 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?
Strict mode is useful in the sense that it prevents unnecessary implicit
conversions (which are costly) and it improves readability.
Following an example:
function foo(string $x, int $y){
bar(1);
return strstr($x,hello, $y);
}
function bar(float $a){}
After adding the implicit conversions the code would look as follows:
function foo(string $x, int $y){
bar((float) 1);
return strstr($x, hello, (bool) $y);
}
function bar(float $a){}
In strict mode the original code would not be valid (rightly so IMO). Just from
reading the original code I would suspect that strstr expects some kind of an
offset (hence the int), therefore strict mode probably revealed a bug.
And if not, then one can add the conversion manually. However, this is not as
trivial as it sounds. Personally I think it would only make sense to have
strict mode in PHP if the user had more strict conversion functions at hand.
What is the benefit of the following? if the conversion to int is as sloppy as
today then one does not gain anything from the strict mode IMO:
function foo(int $x){}
foo( (int)$_GET[bla]);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC Proposal
Hi Tim, As I already told you, you should proceed step by step. Implementing immutable properties *and* removing constants is just a too big step. And, IMO, one may pass, while the second one has no chance, especially if you propose to remove PHP constants as well as class constants, without a BC layer. Unfortunately, while we can sometimes break BC, we are not designing from scratch. Now, if you want to link both features and withdraw the whole, that's your choice, and none will blame you for that. You were asking for opinions that's only mine. Regards François -Message d'origine- De : Tim Bezhashvyly [mailto:tim.bezhashv...@gmail.com] Envoyé : mercredi 18 février 2015 10:44 À : PHP Internals Objet : Re: [PHP-DEV] RFC Proposal Dear internals, my RFC was not about dropping just class constants but constants in general. Now I realise that you are not ready for this and most likely will never be. Thus I’m withdrawing my proposal. Regards, Tim On 18 Feb 2015, at 06:59, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 8:35 PM, Tim Bezhashvyly tim.bezhashv...@gmail.com mailto: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 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] Scalar Type Hints v0.4
On 18 בפבר׳ 2015, at 19:50, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/18/2015 08:51 AM, François Laupretre wrote: De : Pádraic Brady [mailto:padraic.br...@gmail.com] Careful, it helps not to call folk radicals if you intend to pursue a compromise with them ;). Sorry, english is not my native language, and 'radical' may be offensive. I was just looking for a word for people who consider providing two modes is a pre-requisite to any discussion. I wouldn't necessarily mind int-float - it's lossless assuming one way only. It's lossless but it kills the 'strict' position. It can be claimed, one hand on the heart, this will be the only exception but, as use cases and side effects accumulate, we all know it will finish as a bunch of exceptions to a no-more strict mode, adding confusion where it is not needed. I guess the next one would be (int - bool), and the rest would follow. We need to keep in mind that int-float isn't technically lossless. We have a 53-bit IEEE754 mantissa to take account for here, so it is only lossless for values below 36028797018963966 or so. We can limit ourselves to values below that limit. If you deal with values above it, be explicit about casting. Zeev -- 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 7:34 AM, Patrick ALLAERT patrickalla...@php.net wrote: Regarding 2) and 3): An option might be to implement weak mode only and configure the coercion rules reporting in a similar way than with the error_reporting configuration entry. ini_set(coercion_reporting, 0); // current PHP 5.x behaviour The significant problem with this is that it effects not only the current script, but also all callees (until the next time someone flips the bit). So imagine LibraryA.php was written for PHP5, no scalar type hints, and all that comes with it. Your application turns on COERSION_WARNING and calling LibraryA::doStuff(1,2,3); That call is valid because you're a good programmer who reads the manual and knows how to pass the right args. The author of LibraryA, however, wrote it while drunk at a ruby meetup and is depending on weak conversions all over the place. They even need md5(array()) to output 4410ec34d9e6c1a68100ca0ce033fb17 (yes, I know we don't allow that anymore, enjoy the metaphor) My point is that it potentially imposes new warnings on foreign code. -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
De : Patrick ALLAERT [mailto:patrickalla...@php.net] ini_set(coercion_reporting, COERCION_ERROR); // Fail in case of potentially bad coercion foo(7); // int(7) foo(7); // int(7) foo(7 dogs); // Catchable fatal error: Unsafe coercion transforming 7 dogs to 7. The biggest advantage, IMHO, is that you get the exact same result whether you do: foo((int) $value); or: foo($value); ... whatever the mode you are in. Basically, this is weak type hints + something similar to what I contributed in the past with the Array to string conversion notice (see: https://github.com/php/php-src/commit/d81ea16e). Care to share the pro's/con's you see with a solution like that? That's a good idea, IMO. We can add an optional message when a conversion is executed in ZPP macros. It can help. The main drawback is that it is pure runtime check, not suitable for static analysis and related tools. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Feb 17, 2015 at 10: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. I've added a few comments on the PR. Thank you very much. You found about 25 bugs :) All of them except for elseif should be fixed now. I also think printing else if instead of elseif is not a big problem. Pretty-printer may also add or remove brackets in some situations. Two general notes on the RFC: 1. I don't like the ability to specify a different exception as the second param. Assertions are supposed to be used as sanity checks during development, not to throw meaningful and specialized exception types. Having this possibility will probably only encourage bad usage of assert(). It's not a big problem to me, but I'd rather not have this feature. Joe, this is part of your old patch. I really don't care about it. 2. Similar to the EngineExceptions RFC I'm wondering if AssertionException should extend Exception or be in a separate hierarchy. The same argument as with engine exceptions applies: It's pretty unlikely that you want to catch an AssertionException anywhere apart from top-level error handling code and that people using catch(Exception) blocks would accidentally catch assertions. I'm not sure I agree with this, but I wanted to mentioned the concern. This may be changed together with EngineException patch. I started working on it, and I hope I'll show you results tomorrow. Thanks. Dmitry. Nikita
RE: [PHP-DEV] Scalar Type Hints v0.4
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
What if we defined the types as names in the \PHP namespace, but defined
a slightly different algorithm for resolving typehints vs other uses:
function foo(\PHP\types\numeric $a) // unambiguous but unwieldy
function foo(\My\Namespace\numeric $a) // unambiguously *not* a built-in
type
function foo(numeric $a) // ambiguous, resolved at compile time
The name would be resolved as follows:
Given a typehint $type:
1) If $type begins with '\PHP\types\', interpret it it as an internal type.
2) ElseIf $type contains '\', interpret it as a class name, and proceed
with normal class resolution at runtime.
3) ElseIf \PHP\types\$type is the name of a built-in type, interpret it
as that internal type.
4) Else, interpret it as a class name, and proceed with normal class
resolution at runtime.
Basically, this means you can do the following:
class String {}
function accept_scalar_string(string $string) { ... }
function accept_string_object(\String $string) { ... }
The nice thing about this is that if we ever allow users to define
basic types - copy-on-write structs, range types, enums, etc - they
could extend these built-in types.
Does that make sense to anyone, or am I over-complicating things?
Well, that's a solution, at least theoretically speaking.
Frankly, I find it unreadable and I don't see reserving \PHP\types as a clean
solution. IMO, adding semi-virtual namespaces would be mostly confusing and
would just hide the initial name clash issue.
There are a lot of other ways to extend type hinting to user-defined types.
Maybe we will reserve namespaces for this case. In your design, where would
these user types go ? in \PHP\usertype\ ? or would they share \PHP\types with
built-in types (which recreates the same issue) ?
Regards
François
Regards,
--
Rowan Collins
[IMSoP]
--
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
On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre franc...@php.net wrote: Hi Dmitry, Right. That’s what I got from your last reply. But my question was about another post where you are talking about ‘compile time evaluation’ of expressions, which is different from the bare key/value storage I understood first, and poses the problem of compile time evaluation scope (which also exists at runtime). If you just store the expression as a bare string or AST without evaluating it, that’s fine and, even, much better from a performance point of view. I just want to make it clear for me and everyone that there will be no possibility of compile time evaluation. That’s all. right. Again, sorry to insist ;). no problem. Thaks. Dmitry. François I answer the last time. Annotations is just a key value storage, where value may be AST for php expression. Your may do with it whatever you like (traverse, evaluate, compile), but PHP core itself is not going to do anything. Thanks. Dmitry.
RE: [PHP-DEV] Scalar Type Hints v0.4
De : Zeev Suraski [mailto:z...@zend.com]
That means that 42 can coerce into int, and 42.2 can coerce into float,
and int can coerce into float - but not vice versa.
I was wondering : should we systematically reject float to int, or should we
accept it when range fits and fractional part is null ?
Shorter : can 7.0 be considered as an integer ?
Example : if we completely disable float to int :
function foo(int $arg) {}
foo(ceil(any number)); - fails while ceil result is always integer
foo(abs(float)); - the same
On one side, it depends on value, which is not so good. On the other side, we
must consider, the number behind the representation *is* an integer. And PHP
math functions too often return integers as floats (mostly for a question of
range)
Anyway, one more use case against strict mode, as the examples above, while
considered intuitively and technically correct, would fail. And there several
more. Would the solution be to create another exception :) ?
A somewhat sticky points is coercion into boolean. We need to figure this
one out, and hopefully we can come up with something most people can
agree to.
As I already said, with such a C-like syntax, we probably cannot disable (int
- bool), so the same for 'integer string' to bool, as it is natural to give
this the same rule as native int. Not sure for float but I would say OK too, as
C habits prevail IMO.
Another open question would be coercion of float/int into string. This
particular point might be good for a secondary vote, as I imagine people
from both camps won't see this particular conversion as a major deal-breaker
for them (could be wrong).
I don't see the point here. It creates data but there's no ambiguity in the way
to represent it as a string. I think bidirectional 'numeric string' -
int/float conversion is a concept easier to understand and remember.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
De : Patrick ALLAERT [mailto:patrickalla...@php.net] The biggest advantage, IMHO, is that you get the exact same result whether you do: foo((int) $value); or: foo($value); ... whatever the mode you are in. Wrong. Parameter parsing rules are much more restrictive than casting rules. Only 'foo((int)'orange')' would (erroneously) succeed. François -- 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/18/2015 08:51 AM, François Laupretre wrote: De : Pádraic Brady [mailto:padraic.br...@gmail.com] Careful, it helps not to call folk radicals if you intend to pursue a compromise with them ;). Sorry, english is not my native language, and 'radical' may be offensive. I was just looking for a word for people who consider providing two modes is a pre-requisite to any discussion. I wouldn't necessarily mind int-float - it's lossless assuming one way only. It's lossless but it kills the 'strict' position. It can be claimed, one hand on the heart, this will be the only exception but, as use cases and side effects accumulate, we all know it will finish as a bunch of exceptions to a no-more strict mode, adding confusion where it is not needed. I guess the next one would be (int - bool), and the rest would follow. We need to keep in mind that int-float isn't technically lossless. We have a 53-bit IEEE754 mantissa to take account for here, so it is only lossless for values below 36028797018963966 or so. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
On Wed, 2015-02-18 at 16:17 +0100, Nikita Popov wrote:
On Wed, Feb 18, 2015 at 4:06 PM, Cesar Rodas ce...@rodas.me wrote:
On 18/02/15 15:59, Nikita Popov wrote:
On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov dmi...@zend.com wrote:
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.
I agree with Dmitry.
Exporting the AST to userland in PHP 7.0 would be nice. With Dmitry's
work
on assertions we even have a pretty printer for it, which allows us to
convert the AST back to PHP code.
In this matter, how would it be? It'd be awesome if function expects an
AST tree object instead of a value:
function doQuery($table, *$where) {
$where = convert_ast_toSqlWhere($where);
}
doQuery(foobar, $col1 = something AND $col2 == $col3);
Or at least `ast(expr)`, although both would be nice to have.
The problem here is that in most cases we do not actually know what
function will be called at compile time. A very simple example would be to
replace doQuery() with $db-query() and already we don't know what it is
that we're actually calling and whether or not it needs an AST. However
this does not apply to just methods, it's an issue with nearly all calls.
As such PHP cannot know at compile time whether it should issue a normal
call with evaluated arguments or whether it needs to preserve the AST and
pass that. Just keeping the AST around for all calls would be too expensive
(it's a pretty big memory hog).
So rather than having this as a modifier in the function signature, it
would have to be a modifier in the call syntax. E.g. rust uses foo!()
syntax for macros.
Nikita
Wouldn't the trick be to have $col1 be an object instance that uses
operator overloading? So instead of solving the expression, operators
would return the AST.
Was possible with the operator extension
Some old experimental code from 2006
echo query($connection,
array($catalog-Person-id, $catalog-Titles-title. ' ' .
$catalog-Person-name),
new SqlJoin(SqlJoin::TYPE_INNER,
$catalog-Person,
$catalog-Titles,
$catalog-Person-titleId == $catalog-Titles-id),
$catalog-Person-id == 1);
outputs
SELECT Person.id, Titles.title || ' ' || Person.name FROM Person INNER
JOIN Titles ON Person.titleId = Titles.id WHERE Person.id = 1
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
Hi Dmitry,
Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
orm(new Entity(foo))
class Foo {
}
Now I do feel we need to elaborate some sort of named parameters. Doctrine
tries to simplify a lot developer's life by using consistency in default
mapping and only if the user wants to override default behavior he needs to
override a given parameter. This means in a case where you're mapping a
JoinColumn (
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
),
you may only want to specify the onDelete=CASCADE operation instead of
name, referencedColumnName and many other parameters.
Trying to map this in your default parameter passing, we'd have something
like:
orm(
[
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
)
public $address;
As I said, named parameters make a lot of sense when mapping defaults.
Now by looking at this syntax, I still think we're closer to a simple array
implementation (ReflectionClass::getMetadata(string $name)) and having
something like:
[
orm = [
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
]
public $address;
PS: We haven't even started on talking about overrides yet... =\
Regards,
On Wed, Feb 18, 2015 at 12:04 PM, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre franc...@php.net
wrote:
Hi Dmitry,
Right. That’s what I got from your last reply. But my question was about
another post where you are talking about ‘compile time evaluation’ of
expressions, which is different from the bare key/value storage I
understood first, and poses the problem of compile time evaluation scope
(which also exists at runtime).
If you just store the expression as a bare string or AST without
evaluating it, that’s fine and, even, much better from a performance point
of view. I just want to make it clear for me and everyone that there will
be no possibility of compile time evaluation. That’s all.
right.
Again, sorry to insist ;).
no problem.
Thaks. Dmitry.
François
I answer the last time.
Annotations is just a key value storage, where value may be AST for php
expression.
Your may do with it whatever you like (traverse, evaluate, compile), but
PHP core itself is not going to do anything.
Thanks. Dmitry.
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
2015-02-18 22:22 GMT+03:00 Dmitry Stogov dmi...@zend.com: I think the AST API shouldn't use public properties. Using it, we will have to construct the whole tree of objects, duplicating information from AST. I would propose SimpleXML approach instead - construct object only for node(s) we currently access. What about Generators? They can be used nicely for handling AST data. And each node can be constructed as needed during the traversal. Probably this way is better than ArrayAccess
Re: [PHP-DEV] Scalar Type Hints v0.4
François Laupretre wrote on 18/02/2015 18:05:
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
What if we defined the types as names in the \PHP namespace, but defined
a slightly different algorithm for resolving typehints vs other uses:
function foo(\PHP\types\numeric $a) // unambiguous but unwieldy
function foo(\My\Namespace\numeric $a) // unambiguously *not* a built-in
type
function foo(numeric $a) // ambiguous, resolved at compile time
The name would be resolved as follows:
Given a typehint $type:
1) If $type begins with '\PHP\types\', interpret it it as an internal type.
2) ElseIf $type contains '\', interpret it as a class name, and proceed
with normal class resolution at runtime.
3) ElseIf \PHP\types\$type is the name of a built-in type, interpret it
as that internal type.
4) Else, interpret it as a class name, and proceed with normal class
resolution at runtime.
Basically, this means you can do the following:
class String {}
function accept_scalar_string(string $string) { ... }
function accept_string_object(\String $string) { ... }
The nice thing about this is that if we ever allow users to define
basic types - copy-on-write structs, range types, enums, etc - they
could extend these built-in types.
Does that make sense to anyone, or am I over-complicating things?
Well, that's a solution, at least theoretically speaking.
Frankly, I find it unreadable and I don't see reserving \PHP\types as a clean
solution. IMO, adding semi-virtual namespaces would be mostly confusing and
would just hide the initial name clash issue.
There are a lot of other ways to extend type hinting to user-defined types.
Maybe we will reserve namespaces for this case. In your design, where would
these user types go ? in \PHP\usertype\ ? or would they share \PHP\types with
built-in types (which recreates the same issue) ?
They'd use whatever (non-reserved) namespace the implementer wanted. e.g.
namespace Symfony\Component\TypeChecking;
basicType nonNegativeInt extends PHP\types\int {
public function isValid(int $value) {
return $value = 0;
}
}
basicType PositiveInt extends nonNegativeInt {
public function isValid(nonNegativeInt $value) {
return $value != 0;
}
}
Obviously the format of the actual definition is made up off the top of
my head, but it shows how the namespacing would work. There's no need to
reserve a namespace for the user-defined types, because it's no worse a
burden to say you can't name both a type and a class Foo\Bar than to
say you can't name two different classes Foo\Bar.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
On 13 February 2015 at 23:25, Nikita Popov nikita@gmail.com wrote:
Subclassing: Should there be more specific subclasses of EngineException
for particular errors?
It's not obvious that any subclasses would be useful. However using
the code to specify the exact type of error, rather than having to
inspect the message would be good.
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
Even ignoring the BC problem with having EngineExceptions extending
Exception, I think the EngineException needs to be in a different
hierarchy to Exception to be able to write reasonable code in the
future
Without having EngineException in a separate hierarchy of exceptions,
the code below will catch exceptions where the data is 'ok' but there
was a problem with the code, and continue to process items. This is
almost certainly not the correct behaviour when an EngineException has
been encountered.
interface Service {
function foo($item);
}
function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service-foo($item);
}
// Because $service can throw an Exception that is specific to the
// implementation we have to catch \Exception, unless we are going
// to list all possible implementation specific exception types here.
// That would be a subtle case of strong coupling, and when a new
// implementation is made the new exception type would need to
// be added here.
catch(\Exception $e) {
// item was not processable but PHP engine is OK.
$item-markAsErrored();
//Go on to process the next item
}
}
}
To avoid having EngineExceptions in a separate hierarchy, this
function could be converted to:
function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service-foo($item);
}
catch(\EngineException $ee) {
//PHP engine is not stable - lets get out of here.
throw $ee; //or throw new ProcessException($ee)
}
catch(\Exception $e) {
$item-markAsErrored();
}
}
}
However that is bad as i)it's boiler plate to do the correct behaviour
ii) you have to remember to do that everywhere. Having to remember to
do the correct thing, is going to lead to people forgetting.
It will still be necessary to catch all types of Exception in a single
catch block i.e. at the top level of a script to prevent exceptions
being shown to the end user. This could be made easier by having a
common super class for Exception and EngineException. However having
one try block that is required to have multiple catch statements to
catch all different types of exception is not that much of a burden:
try {
runApp();
}
catch(EngineException $e) {
handleException($ee);
}
catch(Exception $e) {
handleException($e);
}
As that would be the only place it would be required to catch both types.
TL:DR EngineException needs to not extend Exception, whether we need a
super class is not as clear.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
I think the AST API shouldn't use public properties.
Using it, we will have to construct the whole tree of objects, duplicating
information from AST.
I would propose SimpleXML approach instead - construct object only for
node(s) we currently access.
So at first we will construct just single object referring to AST root.
Then traversing it we will create and destroy objects for necessary nodes.
To access children I would propose to implementing ArrayAccess interface.
$ast = \php\ast\parse($string);
foreach ($ast as $child) {
echo \t . $child-getKindName() . \n;
foreach ($child as $grandchild) {
echo \t . $child-getKindName() . \n;
}
}
Thanks. Dmitry.
On Wed, Feb 18, 2015 at 10:06 PM, Nikita Popov nikita@gmail.com wrote:
On Wed, Feb 18, 2015 at 4:22 PM, Alexander Lisachenko
lisachenko...@gmail.com wrote:
2015-02-18 17:59 GMT+03:00 Nikita Popov nikita@gmail.com:
Alexander, I would recommend you to split this into two RFCs, one
dealing only with AST export (and maybe pretty printing) and the second one
with the compilation hooks. There's probably a few questions about the
export API that should be discussed that will be forgotten if everyone
focuses on the more complicated, and probably not yet relevant, question of
compilation hooks.
Hello, Nikita! Thanks for you thoughts!
Sounds reasonable for me, because of short timeframe for PHP7. Let's go
with the first part of RFC, because second part is really cumbersome and
can be applied later, eg. in 7.1 I will split this RFC into two parts and
mark first part for 7.0.
Great!
About first part, do you agree with proposed classes and namespace
`Php\Parser`?
Yeah, I'm okay with that namespace. I prefer php\ast as being more
distinctive from existing projects, but that's not really important.
I want to propose to use classes for parser API instead of pure functions
because it can give more usable OO-API for future needs.
I'm okay with having stuff like -getKindName() on the nodes, however I'd
still keep around the free-standing functions, because they can be used
without a node (i.e. you only need the kind AST_FOO and not an instantiated
node).
I also don't see why we need ParserEngine::parse() instead of just a
(namespaced) parse() function. Not a fan of unnecessary wrapper classes.
There is one more notice regarding to the zval nodes, they should be also
exported as objects, not as values. I think we should export coherent nodes
for everything.
What's the advantage of this? Most leaf nodes will be zval nodes and I
feel it would be rather inconvenient if they'd all have extra wrappers. Is
there some specific problem with including the values directly?
Nikita
Re: [PHP-DEV] [RFC][Discussion] Parser extension API
I'm okay with having stuff like -getKindName() on the nodes, however I'd still keep around the free-standing functions, because they can be used without a node (i.e. you only need the kind AST_FOO and not an instantiated node). I think that getting name of kind is useless without value of kind. According to the RFC, there is only one way from user land to get a kind of node: ask a parser for an AST, that will contain nodes. Is there any reason to do getKindName(1), where 1 - is just integer value. I can't see how it can be useful, this information is fully related to the node. I also don't see why we need ParserEngine::parse() instead of just a (namespaced) parse() function. Not a fan of unnecessary wrapper classes. I think that PHP is ugly enough :) We should try to use namespaces and classes with methods to provide a better experience for user land developers. Classes allow for logical composition of common functionality, provides autocompletion in IDE and can be considered as step to standardization of core API. (Today I discussed this question with colleagues that will be great to have all system classes in Php namespace for PHP=7.0) I know, that on engine level, classes aren't native, but you should think about how this feature will be used by developers. Because, creation of API is one-time process, but imagine how many times it will be used by developers. I think, it will be more polite to provide OO-code for modern API. What's the advantage of this? Most leaf nodes will be zval nodes and I feel it would be rather inconvenient if they'd all have extra wrappers. Is there some specific problem with including the values directly? Yes, reason here is the same as for `token_get_all()`. I hear so many WTFs when value can be either simple character or array. Much harder to work with inconsistent data and many libraries performs additional steps to provide better usability (see https://github.com/Andrewsville/PHP-Token-Reflection/blob/1c5ff91ee6877d1fb0f60fab3e3fc562bdb02684/TokenReflection/Stream/StreamBase.php#L100-L108 or https://github.com/lisachenko/go-aop-php/blob/3c381e243367096d47dc9676b3ad7445d7720ba9/src/Instrument/Transformer/MagicConstantTransformer.php#L117 ) So, each element should be represented as common node, this will simplify usage of API.
Re: [PHP-DEV] Scalar Type Hints v0.4
On 18/02/15 17:55, Zeev Suraski wrote: We can limit ourselves to values below that limit. If you deal with values above it, be explicit about casting. This is exactly my problem ... Databases are using 64bit primary keys more and more, and having to worry about going over some limit is the very thing that any 'hinting' should be taking care of! This is the very area where using 32bit builds at least provides a level of protection currently. -- 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
On Wed, Feb 18, 2015 at 8:22 PM, Dmitry Stogov dmi...@zend.com wrote:
I think the AST API shouldn't use public properties.
Using it, we will have to construct the whole tree of objects, duplicating
information from AST.
I would propose SimpleXML approach instead - construct object only for
node(s) we currently access.
So at first we will construct just single object referring to AST root.
Then traversing it we will create and destroy objects for necessary nodes.
To access children I would propose to implementing ArrayAccess interface.
$ast = \php\ast\parse($string);
foreach ($ast as $child) {
echo \t . $child-getKindName() . \n;
foreach ($child as $grandchild) {
echo \t . $child-getKindName() . \n;
}
}
Thanks. Dmitry.
I've considered using this approach, but decided against it because it
introduces a lot of magic for unclear gains. Lazily creating the objects
means we have to keep around the entire AST arena while at least one node
referencing it is alive. So if you're analyzing a large project with a few
thousand files and keep around a few nodes in some cases, you end up not
just with the memory usage of those nodes, but with the memory usage of the
entire ASTs. Furthermore in many cases you'll just traverse the entire AST,
in which case you'll need to instantiate all nodes anyway and the lazy
instantiation will only hurt.
In any case, performance of constructing a full AST is pretty good - I
don't remember the exact numbers, but ast\parse_code() is only slightly
slower than doing token_get_all() on the same code.
Nikita
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi Dmitry,
Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
orm(new Entity(foo))
class Foo {
}
Now I do feel we need to elaborate some sort of named parameters. Doctrine
tries to simplify a lot developer's life by using consistency in default
mapping and only if the user wants to override default behavior he needs to
override a given parameter. This means in a case where you're mapping a
JoinColumn (
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
),
you may only want to specify the onDelete=CASCADE operation instead of
name, referencedColumnName and many other parameters.
Trying to map this in your default parameter passing, we'd have something
like:
orm(
[
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
)
public $address;
As I said, named parameters make a lot of sense when mapping defaults.
Now by looking at this syntax, I still think we're closer to a simple array
implementation (ReflectionClass::getMetadata(string $name)) and having
something like:
[
orm = [
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
]
public $address;
PS: We haven't even started on talking about overrides yet... =\
As a Doctrine user, I find this way worse than current state. This
syntax looks UGLY and contains a lot of useless clutter. And yeah,
adding named parameters to PHP be pretty helpful to make annotations
more readable. :(
And to what Francois said (Anyway, I don't like the OO features
people want to add everywhere. They can get strings and inject them to
OO, but that's not the role of the annotation layer, IMHO. I
definitely prefer the KISS approach.). What's exactly wrong with
doing annotations in an object oriented manner? Both Doctrine
Annotations and C# have them as objects, and it works well. Having
annotations as just array of expressions/strings/whatever and needing
another library to parse them is not really that great upgrade from
current state. :(
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Annotations in PHP7
Hi Guilherme, De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] orm( [ new OneToOne(Address), new JoinColumn(default, default, default, default, CASCADE) ] ) public $address; Why not : orm([ 'OneToOne' = Address, 'JoinColumns' = [ [ 'onDelete' = CASCADE ] ] ]) Can't array keys replace named parameters ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
On 18 February 2015 at 21:50, Anthony Ferrara ircmax...@gmail.com wrote: Static Analysis Is Possible With Weak Declarations The advocacy of allowing `accepts_float(returns_int());` doesn't help the cause of static analysers in strict mode. Java does exactly this and is statically analyzable. So...? As discussed elsewhere. You're absolutely right, it is up to the analyser to throw a warning on this because it is a type-based conversion rather than value based one. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Hi, On Wed, Feb 18, 2015 at 11:23 PM, Leigh lei...@gmail.com wrote: I would like a way of enabling strict by default, immutable to scripts so that users cannot be forced into this mode, and lets the radicals and the weaklings* play together in harmony. For the rest of the RFC, I either agree with or have no strong opinions about the points raised. *it's a joke you guys. I am still bipolar and I still want both to co-exist with no switches and modes. :) No joke. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Leigh, Internal Functions Like ceil() Return Unexpected Types My opinion is that functions should return sane types for their intended purpose, and functions that do not should be fixed. I agree 100%. I just think that's outside the scope of this proposal. Static Analysis Is Possible With Weak Declarations The advocacy of allowing `accepts_float(returns_int());` doesn't help the cause of static analysers in strict mode. Java does exactly this and is statically analyzable. So...? Still no mention of a way to enable strict by default. So lets try some different rationale. If I personally want to develop in strict mode, I can do that with this proposal, I can add a declare to the top of every file and be as strict as I like. However not everyone else is going to want to use my code in strict mode, so they will have to go and remove some/all of those strict declarations. (Lets take callbacks being evaluated in the context they are called rather than the one they are created in). I would like a way of enabling strict by default, immutable to scripts so that users cannot be forced into this mode, and lets the radicals and the weaklings* play together in harmony. I missed that discussion point, so I've just added it: https://wiki.php.net/rfc/scalar_type_hints_v5#why_not_add_an_ini_setting_for_default_mode For the rest of the RFC, I either agree with or have no strong opinions about the points raised. Thanks for the input :-) Anthony -- 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 Wed, Feb 18, 2015 at 10:34 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: 2015-02-18 22:22 GMT+03:00 Dmitry Stogov dmi...@zend.com: I think the AST API shouldn't use public properties. Using it, we will have to construct the whole tree of objects, duplicating information from AST. I would propose SimpleXML approach instead - construct object only for node(s) we currently access. What about Generators? They can be used nicely for handling AST data. And each node can be constructed as needed during the traversal. Probably this way is better than ArrayAccess No. Generators allows only sequential access, while ArrayAccess - random. Thanks. Dmitry.
[PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Dear Internals,
Since the resignation of Andrea, the mixed-mode type hint (called
declaration in the proposal) proposal has been left abandoned.
Considering that the ending votes were 67/34 (66.3%) with several
no-votes being only due to reasonably minor issues with the proposal,
I would like to re-propose her RFC with three minor modifications:
1. declare(strict_types=1) (if used) is required to be the first
instruction in the file only. No other usages allowed.
2. declare(strict_types=1) {} (block mode) is specifically disallowed.
3. int typed variables can resolve a parameter type of float So
calling requiresAFloat(10) will work even in strict mode.
As this topic has and is being discussed to death, I have put a very
large discussion points section:
https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points
I would kindly ask, before replying that you check to see if your
question is answered in that list.
If it is not, please follow up here and I will update the RFC.
If your question is listed and you feel that it wasn't given proper
due, please let's discuss that.
https://wiki.php.net/rfc/scalar_type_hints_v5
Considering this proposal is a minor tweak on an already-discussed and
voted-on proposal, I plan on bringing this RFC to vote 1 week from
today (on February 25th, 2015).
Thanks,
Anthony
--
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 9:40 PM, François Laupretre franc...@php.net wrote: Hi Guilherme, De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] orm( [ new OneToOne(Address), new JoinColumn(default, default, default, default, CASCADE) ] ) public $address; Why not : orm([ 'OneToOne' = Address, 'JoinColumns' = [ [ 'onDelete' = CASCADE ] ] ]) Can't array keys replace named parameters ? yes they can. Regards François
Re: [PHP-DEV] [RFC] Exceptions in the engine
Tony Marston wrote on 18/02/2015 10:52:
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and
an E_WARNING is generated, but it is difficult to trap the error
message (it could be a permissions error, for example). Is there
any plan to convert procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
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,
Could it be restricted to the current scope? In your example the call
to fopen() exists in the load_data() function and is not in a try ...
catch block within *that* function, so the fact that the call to
load_data() is within a try ... catch block should be irrelevant as it
is in a different scope.
If the exception is only thrown when the try - catch is in the same
scope, is there really much advantage to it being an exception? When
you're that close to the code, sticking an if ( $fh === false ) { ... }
around it really isn't that much different from catch(IOException $e) {
... }.
Having the problem be detectable in a higher scope is kind of the point
of exceptions.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
They'd use whatever (non-reserved) namespace the implementer wanted.
e.g.
namespace Symfony\Component\TypeChecking;
basicType nonNegativeInt extends PHP\types\int {
public function isValid(int $value) {
return $value = 0;
}
}
basicType PositiveInt extends nonNegativeInt {
public function isValid(nonNegativeInt $value) {
return $value != 0;
}
}
Interesting. But, if I understand well, these are not classes, as they keep
dealing with scalars. Or we should create an OO API to scalars, which is a very
complex project.
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
On Wed, Feb 18, 2015 at 11:00 PM, Nikita Popov nikita@gmail.com wrote:
On Wed, Feb 18, 2015 at 8:22 PM, Dmitry Stogov dmi...@zend.com wrote:
I think the AST API shouldn't use public properties.
Using it, we will have to construct the whole tree of objects,
duplicating information from AST.
I would propose SimpleXML approach instead - construct object only for
node(s) we currently access.
So at first we will construct just single object referring to AST root.
Then traversing it we will create and destroy objects for necessary nodes.
To access children I would propose to implementing ArrayAccess interface.
$ast = \php\ast\parse($string);
foreach ($ast as $child) {
echo \t . $child-getKindName() . \n;
foreach ($child as $grandchild) {
echo \t . $child-getKindName() . \n;
}
}
Thanks. Dmitry.
I've considered using this approach, but decided against it because it
introduces a lot of magic for unclear gains. Lazily creating the objects
means we have to keep around the entire AST arena while at least one node
referencing it is alive. So if you're analyzing a large project with a few
thousand files and keep around a few nodes in some cases, you end up not
just with the memory usage of those nodes, but with the memory usage of the
entire ASTs. Furthermore in many cases you'll just traverse the entire AST,
in which case you'll need to instantiate all nodes anyway and the lazy
instantiation will only hurt.
In any case, performance of constructing a full AST is pretty good - I
don't remember the exact numbers, but ast\parse_code() is only slightly
slower than doing token_get_all() on the same code.
I think the whole memory usage should be less, because at each point you'll
most probably keep only few AST objects, but I understood your arguments.
They may make sense, but it's hard to say what is better without comparison
of implementations.
Thanks. Dmitry.
Nikita
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi Dmitry,
Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
orm(new Entity(foo))
class Foo {
}
Now I do feel we need to elaborate some sort of named parameters.
Doctrine
tries to simplify a lot developer's life by using consistency in default
mapping and only if the user wants to override default behavior he needs
to
override a given parameter. This means in a case where you're mapping a
JoinColumn (
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
),
you may only want to specify the onDelete=CASCADE operation instead of
name, referencedColumnName and many other parameters.
Trying to map this in your default parameter passing, we'd have something
like:
orm(
[
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
)
public $address;
As I said, named parameters make a lot of sense when mapping defaults.
Now by looking at this syntax, I still think we're closer to a simple
array
implementation (ReflectionClass::getMetadata(string $name)) and having
something like:
[
orm = [
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
]
public $address;
PS: We haven't even started on talking about overrides yet... =\
As a Doctrine user, I find this way worse than current state. This
syntax looks UGLY and contains a lot of useless clutter. And yeah,
adding named parameters to PHP be pretty helpful to make annotations
more readable. :(
This is in no way related, only by the choice of guilherme's syntax. You
could
pass an array of options to the constructor to simulate named easily.
And to what Francois said (Anyway, I don't like the OO features
people want to add everywhere. They can get strings and inject them to
OO, but that's not the role of the annotation layer, IMHO. I
definitely prefer the KISS approach.). What's exactly wrong with
doing annotations in an object oriented manner? Both Doctrine
Annotations and C# have them as objects, and it works well. Having
annotations as just array of expressions/strings/whatever and needing
another library to parse them is not really that great upgrade from
current state. :(
PHP is not primarily an OOP language. As a user of Doctrine you wouldn't
need to care,
because we would wrap it anyway in our current code. So it wouldn't matter.
Regards
Pavel Kouril
Re: [PHP-DEV] RFC Proposal
Hi Tim, Le Wed, 18 Feb 2015 10:44:20 +0100, Tim Bezhashvyly tim.bezhashv...@gmail.com a écrit: Dear internals, my RFC was not about dropping just class constants but constants in general. Now I realise that you are not ready for this and most likely will never be. Thus I’m withdrawing my proposal. Regards, Tim I'm totally against dropping the constants. Constants are one of the first things you learn in PHP, and they are literally everywhere. This would be a major BC. Even worse than DbC, return types and scalar type hints altogether. But the immutable variables are interesting. As other people said, you should proceed step-by-step. I can perfectly see the immutable variables pass, but not the removal of the constants. You should explain precisely what you have in mind, so we can discuss it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
On 18 February 2015 at 20:44, Anthony Ferrara ircmax...@gmail.com wrote:
Dear Internals,
Since the resignation of Andrea, the mixed-mode type hint (called
declaration in the proposal) proposal has been left abandoned.
Considering that the ending votes were 67/34 (66.3%) with several
no-votes being only due to reasonably minor issues with the proposal,
I would like to re-propose her RFC with three minor modifications:
1. declare(strict_types=1) (if used) is required to be the first
instruction in the file only. No other usages allowed.
2. declare(strict_types=1) {} (block mode) is specifically disallowed.
3. int typed variables can resolve a parameter type of float So
calling requiresAFloat(10) will work even in strict mode.
As this topic has and is being discussed to death, I have put a very
large discussion points section:
https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points
I would kindly ask, before replying that you check to see if your
question is answered in that list.
General comments from me, as a radical strictist. No need to reply and
tell me I'm wrong, these are my opinions.
Internal Functions Like ceil() Return Unexpected Types
My opinion is that functions should return sane types for their
intended purpose, and functions that do not should be fixed.
Integers Should Be Accepted For Strict float Arguments
Int-Float Exception Makes Strict Mode Flawed
My opinion is that strict should mean strict.
Static Analysis Is Possible With Weak Declarations
The advocacy of allowing `accepts_float(returns_int());` doesn't help
the cause of static analysers in strict mode.
Why Not Add Support For Null?
I agree a null type is pointless, however I would like to raise the
discussion point of existing hinted optional parameters being allowed
a default of null. i.e. fn(Obj $o = null) {}
Do you think this is acceptable for any other types? I can only think
of it being useful if resource and a generic object type are added.
but others may disagree. (Ideally the resource type will go away over
time and will be replaced with objects like GMP anyway :))
Still no mention of a way to enable strict by default. So lets try
some different rationale. If I personally want to develop in strict
mode, I can do that with this proposal, I can add a declare to the top
of every file and be as strict as I like. However not everyone else is
going to want to use my code in strict mode, so they will have to go
and remove some/all of those strict declarations. (Lets take callbacks
being evaluated in the context they are called rather than the one
they are created in). I would like a way of enabling strict by
default, immutable to scripts so that users cannot be forced into this
mode, and lets the radicals and the weaklings* play together in
harmony.
For the rest of the RFC, I either agree with or have no strong
opinions about the points raised.
*it's a joke you guys.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
Hi List, orm(new Entity(foo)) this may be off-topic. However i'm wondering how this could be an annotation? It looks like code. Why not include this into proper method? What am i missing? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Le Wed Feb 18 2015 at 18:35:02, François Laupretre franc...@php.net a écrit : De : Patrick ALLAERT [mailto:patrickalla...@php.net] ini_set(coercion_reporting, COERCION_ERROR); // Fail in case of potentially bad coercion foo(7); // int(7) foo(7); // int(7) foo(7 dogs); // Catchable fatal error: Unsafe coercion transforming 7 dogs to 7. The biggest advantage, IMHO, is that you get the exact same result whether you do: foo((int) $value); or: foo($value); ... whatever the mode you are in. Basically, this is weak type hints + something similar to what I contributed in the past with the Array to string conversion notice (see: https://github.com/php/php-src/commit/d81ea16e). Care to share the pro's/con's you see with a solution like that? That's a good idea, IMO. We can add an optional message when a conversion is executed in ZPP macros. It can help. The main drawback is that it is pure runtime check, not suitable for static analysis and related tools. Does it sounds like a compromise? ;) More seriously, I'm not sure that should be a prerequisite for accepting an RFC. Patrick
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Albert, On Wed, Feb 18, 2015 at 5:21 PM, Albert Casademont Filella albertcasadem...@gmail.com wrote: Hi Anthony! Thanks for bringing this up again. I am asking you the same I asked Andrea 2 weeks ago on Twitter: make it a triple option vote please. She didn't want to do it, hope you do! This way you eliminate the neverending discussion about weak vs strict, let the votes decide and see who really prefers weak type hinting only and who prefers the stricter way, both camps will have an option to vote. So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes combined need 2/3 of the votes. Then a simple majority of 50%+1 between the different Yes votes is needed. Thanks for the feedback. I have added it to the discussion points: https://wiki.php.net/rfc/scalar_type_hints_v5#this_proposal_should_have_multiple_vote_options The text: This is not a two-part proposal. The proposal is of a unified system that was designed to work together. As such, neither part (weak-only or strict-only) is designed to stand on its own without the other part. Therefore, it only makes sense to vote on this proposal as a whole. Therefore, the voting options this RFC will present will be: Yes and No. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Le Wed Feb 18 2015 at 19:10:54, Sara Golemon poll...@php.net a écrit : On Wed, Feb 18, 2015 at 7:34 AM, Patrick ALLAERT patrickalla...@php.net wrote: Regarding 2) and 3): An option might be to implement weak mode only and configure the coercion rules reporting in a similar way than with the error_reporting configuration entry. ini_set(coercion_reporting, 0); // current PHP 5.x behaviour The significant problem with this is that it effects not only the current script, but also all callees (until the next time someone flips the bit). That precisely my intention. So imagine LibraryA.php was written for PHP5, no scalar type hints, and all that comes with it. Your application turns on COERSION_WARNING and calling LibraryA::doStuff(1,2,3); That call is valid because you're a good programmer who reads the manual and knows how to pass the right args. The author of LibraryA, however, wrote it while drunk at a ruby meetup and is depending on weak conversions all over the place. They even need md5(array()) to output 4410ec34d9e6c1a68100ca0ce033fb17 (yes, I know we don't allow that anymore, enjoy the metaphor) So, by turning it on, I would realise there is something wrong in my LibraryA? My point is that it potentially imposes new warnings on foreign code. Eureka :) That's what happened when I introduced the Array to string conversion: lot of people complained about it and many frameworks had to fix various issues where it happened under the hood (e.g.: with array_diff() on multidimensional arrays). My point is that the same is true when adding E_NOTICE, E_WARNING, E_DEPRECATED,... to the error_reporting: it might prevent libraries to work correctly (read: without extra PHP errors). Why can't strictness follow that path? PS: your feedback makes me feel it would be; even more; a viable option :) Cheers, Patrick
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Hi Anthony!
Thanks for bringing this up again. I am asking you the same I asked Andrea
2 weeks ago on Twitter: make it a triple option vote please. She didn't
want to do it, hope you do! This way you eliminate the neverending
discussion about weak vs strict, let the votes decide and see who really
prefers weak type hinting only and who prefers the stricter way, both camps
will have an option to vote.
So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes
combined need 2/3 of the votes. Then a simple majority of 50%+1 between the
different Yes votes is needed.
Thanks!
Albert
On Wed, Feb 18, 2015 at 9:44 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Dear Internals,
Since the resignation of Andrea, the mixed-mode type hint (called
declaration in the proposal) proposal has been left abandoned.
Considering that the ending votes were 67/34 (66.3%) with several
no-votes being only due to reasonably minor issues with the proposal,
I would like to re-propose her RFC with three minor modifications:
1. declare(strict_types=1) (if used) is required to be the first
instruction in the file only. No other usages allowed.
2. declare(strict_types=1) {} (block mode) is specifically disallowed.
3. int typed variables can resolve a parameter type of float So
calling requiresAFloat(10) will work even in strict mode.
As this topic has and is being discussed to death, I have put a very
large discussion points section:
https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points
I would kindly ask, before replying that you check to see if your
question is answered in that list.
If it is not, please follow up here and I will update the RFC.
If your question is listed and you feel that it wasn't given proper
due, please let's discuss that.
https://wiki.php.net/rfc/scalar_type_hints_v5
Considering this proposal is a minor tweak on an already-discussed and
voted-on proposal, I plan on bringing this RFC to vote 1 week from
today (on February 25th, 2015).
Thanks,
Anthony
--
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 Wed, Feb 18, 2015 at 11:22 AM, Dmitry Stogov dmi...@zend.com wrote: I think the AST API shouldn't use public properties. Using it, we will have to construct the whole tree of objects, duplicating information from AST. I would propose SimpleXML approach instead - construct object only for node(s) we currently access. So at first we will construct just single object referring to AST root. Then traversing it we will create and destroy objects for necessary nodes. I'm not sure if you've seen my astkit extension, but it does this. https://github.com/sgolemon/astkit -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposing [constructive] solutions (was: I quit)
On 02/17/2015 01:15 AM, Kris Craig wrote: To be clear: consensus is not leadership. Consensus cannot be leadership. So the statement leadership of the language is left to consensus is a very explicit and deliberate statement that the language has no leadership. On what basis are you making that assertion? Consensus can be viewed as a form of group leadership, so long as there are sufficient processes involved to facilitate that. It need not necessarily lead to anarchy and disorder, so I don't think it's necessarily a contradiction in terms. The problem with having a single leader calling the shots in this case is that it wouldn't make all the divergent views go away. Instead, we'd probably see a good half a billion or so new hooks to PHP emerging as competing projects. I think that would be far worse than what we have now, even though what we have now is far from perfect. Flat consensus vs. strong dictator deciding everything is a false dichotomy. I make that assertion based on 9 years of experience in Drupal, which despite having a BDFL in theory (Dries) is mostly consensus of whoever notices run. It's a problematic structure that we are currently having some difficult internal discussions about, because it doesn't scale and it's leading to burnout issues, work slowdowns, and other issues. For background, see the presentation I gave on complex informal structures at DrupalCon Amsterdam, which includes a wide array of links to further reading on why informal semi-consensus structures are so problematic: https://amsterdam2014.drupal.org/session/managing-complexity The FIG is a good example of a relatively small group of individuals who decided to draft their style preferences into a set of standards and tried to impose that on everyone else by aggressively billing themselves as the de-facto official standard. I recall on more than one occasion one of their organizers posting here trying to get us to endorse their standard as the official PHP standard. I've also seen them post on places like StackOverflow on at least a couple occasions, interjecting on some unrelated coding question to tell someone their code is not standards-compliant and providing links to the PSR's. I realize this is a tangent, but I always feel a need to push back now whenever someone links to their PSR stuff as an example of what people should be doing. You're fine citing them; I just had to put that little asterisk in there. I'd hate to have to post a link to XKCD's Standards strip again /soapbox That was how FIG started, certainly, under the name PHP Standards Group. I was one of those on the Internals list who called them to task for the initial arrogance before they were booted off of php.net. However, that was 6 years ago. FIG, while still far from perfect, has evolved into a much more productive and useful organization, and I would now put them squarely in the Force For Good(tm) category rather than Force For Evil(tm). That wasn't the case originally, but it is now. The creation of common baseline standards has been a major driver in the PHP Renaissance, and is part of what made tools like Composer possible and seeing the mixing and matching of code from Zend, Symfony, and others as well as modernization efforts like Drupal 8, the new PHP BB, ezPublish, etc. (Disclosure: I joined FIG as the Drupal representative a few months after they were booted off of php.net, a position I still hold. I also co-authored the current voting/process bylaw with Phil Sturgeon.) I think we should be careful not to make this more complicated than it needs to be. Adding a complex new set of rules wouldn't make things any more or less civil. On the whole, I think we do a fairly good job of that on this list. There can be very heated disagreements, sometimes, but you'll find that when you put any group of developers together. So long as people behave like adults and make an effort to be civil, I don't think any special action is needed on our part. Like the FIG, I'd tend to look at it as a solution in search of a problem. --Kris There sounds like there's a great deal of discontent with the current minimalist process. The current RFC process was OMG too much structure compared to the free-for-all that preceded it, but I don't think many people would disagree that adding such structure has greatly improved PHP and the tone of this list. Structure is not a bad thing; bad structure is a bad thing. It's important to understand the difference. Your opinion of FIG is noted, but don't let your distaste for its founding (which I share) cloud you against a potential source of positive inspiration to improve PHP and the PHP development process. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
On 2/18/2015 6:33 PM, Christoph Becker wrote: It seems to me you're thinking too much (maybe only?) about database types. IMHO PHP can be used more versatile, and there might be issues which are exemplified in the RFC[1]: Maybe PHP can be more versatile, but what percentage of PHP code sits between a web browser and a SQL database? I think it is pretty high! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Digit separators for numeric literals
On 2/18/2015 7:44 PM, Rasmus Lerdorf wrote: On 02/18/2015 06:07 PM, Christoph Becker wrote: Hi internals! A while ago a question was asked on the php-general mailing list with regard to digit seperators in numeric literals[1]. IMHO it might be a useful enhancement to allow such digit separators for numeric (integer and float) literals in PHP for better readability; several other languages already support them (such as Java, Perl, Ruby, C#, Eiffel and C++14). Before attempting to draft a respective RFC, I'd like to get some feedback, whether this is generally considered to be useful, which character would be preferred (most other languages seem to allow the underscore, but an apostroph or maybe some other character might be reasonable as well), and which restrictions should be applied (e.g. arbitrary use of the separator, group thousands only, etc.) I'm looking forward to hear your opinion. Thanks in advance. [1] http://marc.info/?l=php-generalm=142143581810951w=2 I think it will be difficult to find a separator character that doesn't make a mess of the grammar. my_func(1,999,999) obviously doesn't work my_func(1'999'999) as per C++14 clashes with our single-quoted strings my_func(1_999_999) like in ADA might work but _999_ would need to work as well and _ is a valid char in a constant so you can have a constant named _999_. - nope # nope @ nope ~ nope ! nope % nope ^ nope We went through this for the namespace char, and there simply isn't a typable single character left to use for something like this. _ is the closest but it would require some changes and BC breaks which I am not sure is worth for what appears to me to be a not-so critical feature. Now if we went into Unicode territory, we could do it. eg. my_func(1 999 999) U+1680 (although it looks too much like a -) my_func(1 999 999) U+205F (mathematical space) my_func(1٬999٬999) U+066C (Arabic thousands separator) my_func(1·999·999) U+00B7 (middle dot) The last one looks best to me, but we'd need a team of people working in shifts to answer the, How do I type this? question. -Rasmus how about: my_func( '1,000.04' ); //if you want to use separators there. Rick. Who is firmly in the camp that considers type juggling an essential feature of PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Am 18.02.2015 um 21:44 schrieb Anthony Ferrara: Since the resignation of Andrea, the mixed-mode type hint (called declaration in the proposal) proposal has been left abandoned. Considering that the ending votes were 67/34 (66.3%) with several no-votes being only due to reasonably minor issues with the proposal, I would like to re-propose her RFC with three minor modifications: What about Sara's Scalar Type Hints v0.4 discussion? I find it disturbing that you take over the RFC without even mentioning this discussion. Please coordinate with Sara first before starting another attempt that will be doomed because some people rather wait for Sara's RFC and a ?php // strict option. 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
On 02/17/2015 12:48 AM, Sara Golemon wrote: Don't mistake me for hack. -Sara No one could ever mistake you for a hack, Sara. :-) --Larry Garfield (Sorry, it was just sitting there...) -- 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 01:30 PM, Zeev Suraski wrote: 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 At this point, if I could rephrase the camps a bit I see two different sets of priorities: 1) PHP should do what seems obviously safe to do, to make life easiest for developers. That is, it's patently obvious that 32 and 32 are equivalent, so don't make developers worry about the distinction because to them there isn't one. This is an entirely reasonable position. 2) PHP would benefit hugely from static analysis tools and compile-time type-based optimizations, but those are only possible with code that is strongly typed. Currently such tools do not really exist, but with compile-time-knowlable information could be written and even incorporated into future versions of PHP without API breaks. (I think Anthony demonstrated earlier examples of function calls no longer being slow, for instance, if the type juggling could be removed at compile time.) This is an entirely reasonable position. Naturally those two positions are mutually exclusive; if the compiler has to allow for 32 to be converted to 32 at runtime, it can't optimize the opcodes by removing the code that would do that conversion! I was against the mixed-mode approach before, but I given the above I am warming to it. The trade off here is between DX (in the sense of the code doing what I mean and not babysitting type information) and potential performance and bug-finding benefits. Different places in an application may need different trade-offs. In practice, the closer you are to an IO action (browser input, database, file, etc.) the more you want the obviously safe behavior; once you pass one layer of specified typing you can be pretty confident that strict checks will just work from there on out. In essence, opt-in-strict becomes an opt-in compiler, be pedantic so you can make my code faster flag. More carrot than stick, since people can control when they opt-in to fancier compiler optimizations at the cost of some DX, but only in some cases. I started this email planning to ask Anthony how flexible strict checking could get without losing the benefits of it, but I think I've just convinced myself the answer is not very. Which then leaves only the question of internal functions that Rasmus raised, which... it looks like is discussed in later emails so I will try to catch up on those. :-) --Larry Garfield -- PHP Internals - PHP
Re: [PHP-DEV] Digit separators for numeric literals
On 19/02/15 03:44, Rasmus Lerdorf wrote: but _999_ would need to work as well and _ is a valid char in a constant so you can have a constant named _999_. Why would we need to support the underscore in front (and maybe even at the end) of a number? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
Morning, I hear the concern regarding custom exceptions. Things will be used badly whatever. It's easy to imagine that in a simple application you just don't need to specify custom exceptions. But in a large codebase, being able to structure exceptions is invaluable, it gives documentation reference points and makes stack traces easier to read at a glance, because they are more meaningful. So I think we should keep the ability to throw custom exceptions. I agree about making the exception part of a new tree, so that they are not caught, so I'll just wait for that from dmitry and open the vote. Cheers Joe On Wed, Feb 18, 2015 at 5:01 PM, Dmitry Stogov dmi...@zend.com wrote: On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Feb 17, 2015 at 10: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. I've added a few comments on the PR. Thank you very much. You found about 25 bugs :) All of them except for elseif should be fixed now. I also think printing else if instead of elseif is not a big problem. Pretty-printer may also add or remove brackets in some situations. Two general notes on the RFC: 1. I don't like the ability to specify a different exception as the second param. Assertions are supposed to be used as sanity checks during development, not to throw meaningful and specialized exception types. Having this possibility will probably only encourage bad usage of assert(). It's not a big problem to me, but I'd rather not have this feature. Joe, this is part of your old patch. I really don't care about it. 2. Similar to the EngineExceptions RFC I'm wondering if AssertionException should extend Exception or be in a separate hierarchy. The same argument as with engine exceptions applies: It's pretty unlikely that you want to catch an AssertionException anywhere apart from top-level error handling code and that people using catch(Exception) blocks would accidentally catch assertions. I'm not sure I agree with this, but I wanted to mentioned the concern. This may be changed together with EngineException patch. I started working on it, and I hope I'll show you results tomorrow. Thanks. Dmitry. Nikita
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Am 19.02.2015 um 05:21 schrieb Dennis Birkholz: Am 18.02.2015 um 21:44 schrieb Anthony Ferrara: Since the resignation of Andrea, the mixed-mode type hint (called declaration in the proposal) proposal has been left abandoned. Considering that the ending votes were 67/34 (66.3%) with several no-votes being only due to reasonably minor issues with the proposal, I would like to re-propose her RFC with three minor modifications: What about Sara's Scalar Type Hints v0.4 discussion? I find it disturbing that you take over the RFC without even mentioning this discussion. Please coordinate with Sara first before starting another attempt that will be doomed because some people rather wait for Sara's RFC and a ?php // strict option. I just saw the reddit where you mention that v0.4 is practically abandoned now, so I will just renounce my previous mail! Will you consider to let the people vote on how to enable strict mode like discussed in the v0.4 discussion? Like this here from the Reviving scalar type hints thread? Am 17.02.2015 um 00:58 schrieb Sara Golemon: 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 Thanks Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Thu, Feb 19, 2015 at 2:12 AM, François Laupretre franc...@php.net wrote: If I understand Dmitry correctly, this would be stored as the compiler internal representation of the 'new Entity(foo)' code, but this wouldn't be executed until an external mechanism decides to do so. So, this is PHP code and it is compiled and stored in memory besides the function opcodes, but not evaluated. Right. It's even not compiled into bytecode, just parsed into AST and then associated with function/class/property like doc-comment. You're right, it contains code. The key point is that this code will never be executed nor used in any way until an external mechanism decides to retrieve and evaluate it. That's metadata. Right again. Thanks. Dmirty. Regards François -Message d'origine- De : Crypto Compress [mailto:cryptocompr...@googlemail.com] Envoyé : mercredi 18 février 2015 23:11 À : PHP Developers Mailing List Objet : Re: [PHP-DEV] Annotations in PHP7 Hi List, orm(new Entity(foo)) this may be off-topic. However i'm wondering how this could be an annotation? It looks like code. Why not include this into proper method? What am i missing? -- 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
Hi! 2) PHP would benefit hugely from static analysis tools and compile-time type-based optimizations, but those are only possible with code that is strongly typed. Currently such tools do not really exist, but with Is that really the case? Javascript has very good optimizing engine, and Javascript has no typing. Of course, it is probably *easier* with strict types, but harder and impossible are two very different things. In fact, I do not see large benefits for static analysis from scalar typing - execution path rarely is different depending on if something is integer or string, except for obvious is_* check - but those are rarely controlling any useful logic. It may be different depending on if it's a scalar or an object - but that we already have covered. -- 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][Discussion] Parser extension API
On Thu, Feb 19, 2015 at 8:42 AM, Sara Golemon poll...@php.net wrote: On Wed, Feb 18, 2015 at 11:22 AM, Dmitry Stogov dmi...@zend.com wrote: I think the AST API shouldn't use public properties. Using it, we will have to construct the whole tree of objects, duplicating information from AST. I would propose SimpleXML approach instead - construct object only for node(s) we currently access. So at first we will construct just single object referring to AST root. Then traversing it we will create and destroy objects for necessary nodes. I'm not sure if you've seen my astkit extension, but it does this. https://github.com/sgolemon/astkit I didn't see it before, and took just a quick look, but I like it. Any special reason, why you didn't implement ArrayAccess interface for children access? For me it would look natural. Thanks. Dmitry. -Sara
Re: [PHP-DEV] Digit separators for numeric literals
On 02/18/2015 11:21 PM, Rick Widmer wrote: On 2/18/2015 7:44 PM, Rasmus Lerdorf wrote: Now if we went into Unicode territory, we could do it. eg. my_func(1 999 999) U+1680 (although it looks too much like a -) my_func(1 999 999) U+205F (mathematical space) my_func(1٬999٬999) U+066C (Arabic thousands separator) my_func(1·999·999) U+00B7 (middle dot) The last one looks best to me, but we'd need a team of people working in shifts to answer the, How do I type this? question. -Rasmus how about: my_func( '1,000.04' ); //if you want to use separators there. The problem with that is that the world is split. The other half, or actually more than half, would write that as '1.000,04'. There is no way we would want to take sides on that one. And we have support for locale-based number formatting and parsing via numfmt_format() and numfmt_parse(). If we were going to add a separator for literals, the only real low-ascii choice is _ which is also used by Ada, D, Java, Perl and Ruby. I was 90% kidding about using a Unicode character, but if you think about it a bit, most people are using IDEs or at least smart scriptable editors, it wouldn't be that much of a stretch to picture your editor pretty-printing 1234567890 as 1·234·567·890 or 1˙234˙567˙890 (U+02D9). It would be easy to make the parser ignore that character in numeric literals. Much easier than working out the various issues with _ anyway. Although, personally it would freak me out if my editor started messing with my numbers on me. But I don't use an IDE. I don't even have syntax-highlighting turned on in my vim config. We didn't have stuff like that on the Wyse 50. -Rasmus signature.asc Description: OpenPGP digital signature
RE: [PHP-DEV] Scalar Type Hints v0.4
De : Zeev Suraski [mailto:z...@zend.com] If we do implement the single-mode, stricter-than-pure-weak and weaker-than-pure-strict ruleset, we could introduce a new set of conversion functions, along the lines of safe_int(), that would follow the same rules as the corresponding type hints (i.e. accept (int) 32, (string) 32, but not (float) 32.7, or (string) 32 dogs). Nice. I like it : create a set of userland functions aligned on zend_parse_arg_xxx(). Just remains to bikeshed on function names :) Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
De : Pádraic Brady [mailto:padraic.br...@gmail.com] However, “123” is exceptional. It’s redefining an integer as “ an integer or a string comprised wholly of digits without leading zeroes, with an optional leading hyphen, and representing an integer up to PHP_INT_MAX” Add leading zeros, and leading/trailing blanks and I think it is still strict enough. Then again, it’s an exception that requires a long sentence. It’s just not clear, to me, if this is the sole intended exception, or if that sentence needs to be expanded to a paragraph. A section? Are we going to need a chapter? I’m assuming octals-in-a-string are a no-go to be coerced whereas others might just see an integer with superfluous leading zeroes. Leading zeros to recognize octal string are not an option, but alternative non ambiguous syntax is possible, in theory. '0x'-prefixed hexa is possible too. Thoughts ? In a future RFC revision, it might be nice to have a table of the specific coercion rules applicable to a weak/strong/single-unified option. I am currently writing this. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
Hi, Octal is something that can often be miss converted since it IS the same as an integer with only a '0' in front in PHP. But that is not something that can be fixed with the current proposals? What do you propose ? Considering leading zero as octal indicator is not an option, IMO. If you have another way, why not. Again we have to ensure that the pre-processing takes care of the problem and how would static analysis even know there was a problem? A type hint following the SQL standards. Please give conversion rules and supported syntax for the 'SQL' type you have in mind. would be more helpful than the javascript approach of giving an error in strict mode. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Leigh wrote on 18/02/2015 13:10: 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. This leaves us in a state where some functions will have defined types with their aggressive coersion rules and some will not, and we can't expect users to remember which set of functions have been updated or not. That's precisely the case for every existing user-defined function. Switching to PHP 7 won't suddenly add type hints to every function in every library and every existing bespoke code base, so there is no way to avoid that thought process. I think the rules need to apply to everything or nothing. The rules will apply to everything in the same way - if a function is typehinted, it behaves like so; if it's not, it behaves the same way it did in PHP 5. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and on
the
very first if it was a strict hint:
for ($i = 0; $i 11; $i++)
{
foo(base_convert($i, 10, 16));
}
And when I said leading zeros, I was talking about fixed-length string
identifiers such as '001', '002', etc. where you may *unintentionally*
pass
such a value to a function that deals with ... quantities, for example. A
strict
hint in that case would immediately catch this logical error while a weak
hint
would silently ignore the leading zeros and will happily treat the value
as an
integer. Again, the precondition here is that it's not an integer value
that
happens to be stored as a string, but a non-integer value that just looks
like
an integer.
Thanks the example Andrey, it's helpful.
My goal with asking for these use cases isn't to claim that they never
exist, and I certainly don't want to get into a theological discussion. My
goal is to try and figure out whether many, if not all, proponents of strict
typing would be willing to live with a compromise on single set of rules,
that on one hand would be a lot stricter than what was proposed for weak
typing in the v0.3 RFC (bool-anything fails, any string that's not strictly
looking like a number incl. 100 dogs - int/float fails, float-int
fails), but on the other hand, would allow certain lossless conversions
(numeric string - int/float, int-float, toString() to string, etc.) to
work.
When people from both schools of thought (strict/weak) come to evaluate this
possibility, remember that we don't need a solution that works in 100.0% of
the cases. Edge cases, again, be them strict or weak, can always be
implemented with a bit of custom code inside the function - the important
thing is to get a system that addresses the vast majority of cases.
Thanks!
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Hi,
On Wed, Feb 18, 2015 at 2:27 PM, François Laupretre franc...@php.net wrote:
Hi Andrey,
De : Andrey Andreev [mailto:n...@devilix.net]
I too am curious about the potential issue with 123 to 123
specifically, although it could be seen as a subset of another problem
that is solved with strict hints - numeric-character string
identifiers being erroneously treated as integers.
Please give use cases. Do you want to support '0xhexa' strings ? that's
possible. We are not only restricting possible conversions, we can also
support additional syntaxes. Just give use cases for what you think should be
enabled or disabled, compared to the current behavior.
The only change we have in list so far about (string - number) is rejecting
trailing chars (but accepting trailing blanks).
We are in the process of changing these rules so, please give examples of '
numeric-character string identifiers being erroneously treated as integers'.
If you mean '7 years', it's in list already. If others, tell us.
That is especially bad when such identifiers are in fact generated as
integers first so that they are incremental, but the
program/database/business logic requires them to be fixed-length
strings and/or in hexadecimal format. In such cases, even silently
discarding leading zeros can prove to be problematic, while in the
case of hexadecimal representations you'd need more than 10 data
samples to notice the problem if you don't use a strict hint.
Do you mean we should accept hexadecimal string as int ? why not ? Give exact
syntax(es) you want to support (except leading/trailing blanks, which are
default now).
No, I meant the opposite ... I was trying to explain cases where a
weak hint would be insufficient. Sorry for not including examples in
my first mail, I did that in my next reply:
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and
on the very first if it was a strict hint:
for ($i = 0; $i 11; $i++)
{
foo(base_convert($i, 10, 16));
}
And when I said leading zeros, I was talking about fixed-length string
identifiers such as '001', '002', etc. where you may *unintentionally*
pass such a value to a function that deals with ... quantities, for
example. A strict hint in that case would immediately catch this
logical error while a weak hint would silently ignore the leading
zeros and will happily treat the value as an integer. Again, the
precondition here is that it's not an integer value that happens to be
stored as a string, but a non-integer value that just looks like an
integer.
Cheers,
Andrey.
--
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 18 February 2015 at 13:18, Rowan Collins rowan.coll...@gmail.com wrote: This leaves us in a state where some functions will have defined types with their aggressive coersion rules and some will not, and we can't expect users to remember which set of functions have been updated or not. That's precisely the case for every existing user-defined function. Switching to PHP 7 won't suddenly add type hints to every function in every library and every existing bespoke code base, so there is no way to avoid that thought process. Of course, and some people may opt to avoid type hints altogether in their own code to avoid this, but they can't avoid changes to internal functions. How do we plan to release these incremental changes? We try and minimise BC as much as possible so a patch release might not be possible. Do we restrict it to minor versions, i.e. the yearly release schedule? I think the rules need to apply to everything or nothing. The rules will apply to everything in the same way - if a function is typehinted, it behaves like so; if it's not, it behaves the same way it did in PHP 5. That's not really what I meant. So a user doesn't have to keep track of which internal functions are now typed and which are not, all functions should be typed at the same time, or none at all. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
De : Robert Stoll [mailto:p...@tutteli.ch]
Strict mode is useful in the sense that it prevents unnecessary implicit
conversions (which are costly) and it improves readability.
Following an example:
function foo(string $x, int $y){
bar(1);
return strstr($x,hello, $y);
}
function bar(float $a){}
After adding the implicit conversions the code would look as follows:
function foo(string $x, int $y){
bar((float) 1);
return strstr($x, hello, (bool) $y);
}
function bar(float $a){}
In strict mode the original code would not be valid (rightly so IMO).
Actually, your example is partially invalid because strict-typing radicals now
propose to add a (int - float) exception to so-called strict mode (which
proves the approach is flawed, IMHO).
You don't propose a strict-mode alternative in your example. OK, it generates
conversions and should fail. Now, how would you write the same code using
strict-mode and without adding casts which would do exactly the same, but
slower.
If you just mean there's an undetected bug, you're right, but, IMO, a C-like
syntax like PHP's cannot disable (int - bool) implicit conversion.
A partial solution can be brought by a set of strict types I am planning to
define in the single (not so weak) mode approach I am working on (something
like 'int!', 'float!',...). This would allow people who know what they're doing
to demand zval-type-based strict checks, arg by arg. It can be used for
performance reasons and for the rare cases where zval type really matters
(sorting, for instance). This would be available to internal and userland
functions.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Leigh wrote on 18/02/2015 13:31: On 18 February 2015 at 13:18, Rowan Collins rowan.coll...@gmail.com wrote: This leaves us in a state where some functions will have defined types with their aggressive coersion rules and some will not, and we can't expect users to remember which set of functions have been updated or not. That's precisely the case for every existing user-defined function. Switching to PHP 7 won't suddenly add type hints to every function in every library and every existing bespoke code base, so there is no way to avoid that thought process. Of course, and some people may opt to avoid type hints altogether in their own code to avoid this, but they can't avoid changes to internal functions. How do we plan to release these incremental changes? We try and minimise BC as much as possible so a patch release might not be possible. Do we restrict it to minor versions, i.e. the yearly release schedule? Yes, I think that would be sensible. The aim would still be for most internal functions to have type hints by 7.0, since most of them have trivial signatures, particularly if we can agree a suitable set of union types. Internal function signatures (which are currently only signatures in the manual, and a bunch of procedural ZPP magic in the source) change between minor versions fairly often, so function x will now raise errors in strict typing mode for values that would previously have been accepted seems a reasonable change note for 7.1, 7.2, etc. I can't foresee any reason why we'd urgently want to add a typehint in a patch release. I can, though, see a rush to get every internal function typehinted by using ZPP causing unintended consequences, and us having to rush out fixes in 7.0.1. I think the rules need to apply to everything or nothing. The rules will apply to everything in the same way - if a function is typehinted, it behaves like so; if it's not, it behaves the same way it did in PHP 5. That's not really what I meant. So a user doesn't have to keep track of which internal functions are now typed and which are not, all functions should be typed at the same time, or none at all. Yes, I'm sorry, I deliberately took the sentence more generally than it was intended in order to make a different point. I find the lack of consistency between internal and user-defined functions really frustrating as a user, so am always on the look out for rules that can apply neatly to them both. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On Tue, Feb 17, 2015 at 10: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. I've added a few comments on the PR. Two general notes on the RFC: 1. I don't like the ability to specify a different exception as the second param. Assertions are supposed to be used as sanity checks during development, not to throw meaningful and specialized exception types. Having this possibility will probably only encourage bad usage of assert(). It's not a big problem to me, but I'd rather not have this feature. 2. Similar to the EngineExceptions RFC I'm wondering if AssertionException should extend Exception or be in a separate hierarchy. The same argument as with engine exceptions applies: It's pretty unlikely that you want to catch an AssertionException anywhere apart from top-level error handling code and that people using catch(Exception) blocks would accidentally catch assertions. I'm not sure I agree with this, but I wanted to mentioned the concern. Nikita
Re: [PHP-DEV] Scalar Type Hints v0.4
On 18 February 2015 at 14:40, Lester Caine les...@lsces.co.uk wrote: But my favourite is still '\143\141\164' == \143\141\164 which is false, but I doubt many would know why? Pretty sure one of the first things PHP devs learn is that single quoted strings only accept \' and \\ as escape sequences. -- 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 18/02/15 12:33, François Laupretre wrote: Octal is something that can often be miss converted since it IS the same as an integer with only a '0' in front in PHP. But that is not something that can be fixed with the current proposals? What do you propose ? Considering leading zero as octal indicator is not an option, IMO. If you have another way, why not. 0o 0 and \ are the usual flags for an octal value and we have functions for octal strings but they are not user friendly in their output as they tend to ignore adding a leading tag at all. But my favourite is still '\143\141\164' == \143\141\164 which is false, but I doubt many would know why? Yes it only becomes a problem when one is accessing material like historic data dumps, and rejecting the numeric string may be 'strictly' correct, but it's one those 'what the' if one gets an error where for years it's run perfectly? Again we have to ensure that the pre-processing takes care of the problem and how would static analysis even know there was a problem? A type hint following the SQL standards. Please give conversion rules and supported syntax for the 'SQL' type you have in mind. 'octal' just expects a base 8 string. I know there are some examples in the SQL standards, but since they are paid for documents it's pointless trying to reference them :( ( Andrey - there may not be plans to support a full range of hints - weak or strict, but this is all valid material that PHP handles daily and passes around ) -- 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
Hi all, On 18 February 2015 at 09:14, Andrey Andreev n...@devilix.net wrote: Hi, On Wed, Feb 18, 2015 at 9:00 AM, Zeev Suraski z...@zend.com wrote: 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? I too am curious about the potential issue with 123 to 123 specifically, although it could be seen as a subset of another problem that is solved with strict hints - numeric-character string identifiers being erroneously treated as integers. If I may interject briefly (doing it anyway!), there are so many concepts being munged together that there's bound to be confusion (on the part of idle readers like me). For this specific case, would I as someone who wants strict/strong typing really care whether “123” was coerced to an integer? No. Others are free to disagree. I actually don’t mind there being a certain amount of logical coercion between types where it makes sense. That’s not, per se, fully in accordance with strictest to the strict degree typing which was Nikita’s point. Coercion is itself a symptom of weak typing, so the more coercion one introduces, the weaker the typing. However, “123” is exceptional. It’s redefining an integer as “ an integer or a string comprised wholly of digits without leading zeroes, with an optional leading hyphen, and representing an integer up to PHP_INT_MAX”, i.e. an integer or a string with a real number that be made an integer without loss. No other string need apply. That’s not strict-strict typing (there’s coercion) but it’s probably strict enough to pass muster (it’s one single obvious coercion under limited circumstances). Then again, it’s an exception that requires a long sentence. It’s just not clear, to me, if this is the sole intended exception, or if that sentence needs to be expanded to a paragraph. A section? Are we going to need a chapter? I’m assuming octals-in-a-string are a no-go to be coerced whereas others might just see an integer with superfluous leading zeroes. In a future RFC revision, it might be nice to have a table of the specific coercion rules applicable to a weak/strong/single-unified option. Granted, final implementation details may be not 100% certain, but in this case any variation in implementation can have significance as to whether something is weak/strict/or lies somewhere else on the spectrum in between. So, I agree with Nikita that this is less than strict typing, but one single logical exception doesn’t instantly demote it to extreme weak typing if its sufficiently narrow in scope. We are compromising, no? It’s imperfect in other ways, but I’ll let others debate if those are significant or not. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Michael Wallner wrote on 18/02/2015 11:39: On 18/02/15 12:31, Rowan Collins wrote: Michael Wallner wrote on 18/02/2015 11:19: On 17/02/15 23:03, Sara Golemon wrote: 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) Hold on, usually, type checking functions don't identify NULL as scalar. No need for anyone to hold on; as it says in the section you've quoted we can argue what's in this list separately. Sara's after reactions to the principle of having meta-types/unions in general, not their definitions, right now. Did you already incorporate strict mode yourself? SCNR I'm not a native speaker, so hold on might mean something different to you than to me. Sorry, what I meant was, don't worry, this isn't the kind of issue that we need to worry about yet. Sara's e-mail made clear that these were quick examples, and she wasn't expecting feedback on the details at this stage. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
Hi Andrey, De : Andrey Andreev [mailto:n...@devilix.net] I too am curious about the potential issue with 123 to 123 specifically, although it could be seen as a subset of another problem that is solved with strict hints - numeric-character string identifiers being erroneously treated as integers. Please give use cases. Do you want to support '0xhexa' strings ? that's possible. We are not only restricting possible conversions, we can also support additional syntaxes. Just give use cases for what you think should be enabled or disabled, compared to the current behavior. The only change we have in list so far about (string - number) is rejecting trailing chars (but accepting trailing blanks). We are in the process of changing these rules so, please give examples of ' numeric-character string identifiers being erroneously treated as integers'. If you mean '7 years', it's in list already. If others, tell us. That is especially bad when such identifiers are in fact generated as integers first so that they are incremental, but the program/database/business logic requires them to be fixed-length strings and/or in hexadecimal format. In such cases, even silently discarding leading zeros can prove to be problematic, while in the case of hexadecimal representations you'd need more than 10 data samples to notice the problem if you don't use a strict hint. Do you mean we should accept hexadecimal string as int ? why not ? Give exact syntax(es) you want to support (except leading/trailing blanks, which are default now). Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
-Original Message-
From: Robert Stoll [mailto:p...@tutteli.ch]
Sent: Wednesday, February 18, 2015 1:14 PM
To: 'Zeev Suraski'; 'Nikita Popov'; 'Rasmus Lerdorf'
Cc: 'Sara Golemon'; 'PHP internals'
Subject: AW: [PHP-DEV] Scalar Type Hints v0.4
-Ursprüngliche Nachricht-
Von: Zeev Suraski [mailto:z...@zend.com]
Gesendet: Mittwoch, 18. Februar 2015 08:00
An: Nikita Popov; Rasmus Lerdorf
Cc: Sara Golemon; PHP internals
Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
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?
Strict mode is useful in the sense that it prevents unnecessary implicit
conversions (which are costly) and it improves readability.
Following an example:
function foo(string $x, int $y){
bar(1);
return strstr($x,hello, $y);
}
function bar(float $a){}
After adding the implicit conversions the code would look as follows:
function foo(string $x, int $y){
bar((float) 1);
return strstr($x, hello, (bool) $y); }
function bar(float $a){}
In strict mode the original code would not be valid (rightly so IMO). Just
from
reading the original code I would suspect that strstr expects some kind of
an
offset (hence the int), therefore strict mode probably revealed a bug.
There are two things I'm not so clear about in what you're saying.
It seems that the 2nd sample adds explicit casts and not implicit casts.
Explicit casts are actually use a much more aggressive ruleset than even the
ruleset in the v0.3 RFC, in the sense that they'd happily convert Apple
into (float) 0.0, if you do an explicit (float) cast. They (almost) can't
fail.
Secondly, I think there aren't any common situations where strict typing (in
the form of zval.type comparison) would be any less costly than weak typing.
The difference is really between failure (abort in case there's a type
mismatch in strict) and success (convert to the requested type). The
conversion that may happen in the weak scenario is no costlier than an
explicit cast, probably a tiny bit less actually.
Again, in my opinion pushing users towards explicit casts - which have much
more lax rules than the ones proposed in v0.3, let alone the ones we're
currently considering, will defeat the purpose and actually make finding
bugs harder.
And if not, then one can add the conversion manually. However, this is not
as
trivial as it sounds. Personally I think it would only make sense to have
strict
mode in PHP if the user had more strict conversion functions at hand. What
is
the benefit of the following? if the conversion to int is as sloppy as
today
then one does not gain anything from the strict mode IMO:
function foo(int $x){}
foo( (int)$_GET[bla]);
I agree, but changing the rules of explicit casts is a *huge* change and BC
break. If we do implement the single-mode, stricter-than-pure-weak and
weaker-than-pure-strict ruleset, we could introduce a new set of conversion
functions, along the lines of safe_int(), that would follow the same rules
as the corresponding type hints (i.e. accept (int) 32, (string) 32, but
not (float) 32.7, or (string) 32 dogs).
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Annotations in PHP7
De : Benjamin Eberlei [mailto:kont...@beberlei.de]
nested can be done in any way, its a statement so the following would work:
orm(new JoinTable(['joinColumns' = [new JoinColumn('id', 'other_id')]]))
Dmitry is planning compile time evaluation, which is probably the only way to
do it if we use PHP expressions. Is class instantiation, or function call
returning a new object instance (I guess) compatible with compile time
evaluation ?
More : would userland functions be available (if already defined, of course) ?
if yes, what about functions defined in the same file but below the annotation
calling it ? Two-pass ?
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Nightmares on type hints, annotations, and aop...
After a spate of literal coding nightmares, I woke needing to commit these
thoughts to the list. These may have been raised before, I can't remember,
these debate has been raging for so long.
THING 1: Hints are just is_* wrappers
function f(scalar $s, int $i) { }
effectively is sugar for:
function f($s, $i) {
if (! is_scalar($s)) throw new \InvalidArgumentException();
if (! is_int($i)) throw new \InvalidArgumentException();
}
THING 2: Hints are truthy callables
function my_mixed($m) {
return (null === $m || is_string($m));
}
function f(is_scalar $s, is_int $i, my_mixed $m) {};
THING 3: Pre- and post- blocks to define contracts, establish formal join
points, with or without hints from above
function f($s, $i, $m)
before {
if (! is_scalar($s)) throw new \InvalidArgumentException;
},
inside {
$fp = fopen($s, 'r');
return [ $i, $m ];
},
after ($retval) {
assert(is_array($retval) 2 === count($retval));
},
finally ($retval) {
fclose($fp);
if ($retval instanceof \Exception) {
// I got here by an unhandled exception
}
}
weave('before', 'f', function ($s, $i, $m) {
syslog(LOG_DEBUG, __POINTCUT__); // is 'f'
}
I had to get these off my chest. Forgive me their implementation ignorance.
I am yet tired and uncaffeinated. To the void I commit their bodies...
bishop
RE: [PHP-DEV] Scalar Type Hints v0.4
De : Andrey Andreev [mailto:n...@devilix.net]
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and
on the very first if it was a strict hint:
for ($i = 0; $i 11; $i++)
{
foo(base_convert($i, 10, 16));
}
You're right. An hexa string with no leading '0x' and containing decimal digits
only cannot be recognized as hexa. But I keep thinking that, balancing pros and
cons, it's not enough to justify strict mode. Maybe I'm wrong and additional
use cases will make me change my mind, but I consider hexa with no prefix as an
edge-case.
I don't say that's the right solution but the problem can be solved at the
base_convert() level. If we support '0x' strings as hexadecimal numbers, it can
generate the '0x' prefix, which removes ambiguity for PHP and any other
software that would have to interpret the string. Unfortunately, it would
probably have to be explicitly required through an option because of BC. No
perfect solution here.
Another argument some may consider weak : I'm also afraid that, in your
example, the user seeing an error raised by strict mode could change its code
to 'foo((int)base_convert', definitely hiding the real bug, even for 11 and up.
So, Rasmus is right when he says strict mode can sometimes and indirectly be
counter-productive. Debugging shouldn't be considered as error suppression
only, but it is the case more than often.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
Hi Nikita, 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. (*) Please refer to my other posts proposing single mode with the addition of four 'strict' scalar types at ZPP level (would apply to internal *and*userland). These will be chosen by internal function implementors when they decide it, not by the caller. I hope it can solve your question. The idea is that internal function are treated as weak using the current ZPP types. Then, they can be made strict, one by one, and argument by argument. No need to duplicate type hinting to arg_info IMO. Rasmus' (int - float) coercion question does not exist if we find a single mode consensus. And, I am decided to take the time it needs to find one, as I think it can lead to a much more consistent design. Can you just tell me if what I exposed above solves your concerns ? Thanks. Regards François -- 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 17 February 2015 at 22:03, 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) Can we keep a 0) of reserve names for future use in-case of RFC failure option. 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... How do you propose weak typing works with these? Does it only allow one of the union of types through (thus making it strict), or does it try and coerce to one if it can? Which one does it pick? 2) Define a way to enable strict mode (we'll be weak by default). Please give the option to enable strict by default. This is all many of us have been asking for. Personally I don't care if this cannot be changed from a script to prevent it being forced on users (yes I'd be willing to have it as an ini setting even...). Just the option, that's all we want. 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. This leaves us in a state where some functions will have defined types with their aggressive coersion rules and some will not, and we can't expect users to remember which set of functions have been updated or not. I think the rules need to apply to everything or nothing. 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. So there will be potential ongoing breaks for any type of callers as and when functions receive their types. No type is existing behaviour(?), typed + weak is aggressive coersion that may fail where untyped did not (from 3b), and typed + strict wont throw until the function is typed. Unrelated to the specifics of this proposal, I've had a quick search (for things like locale and LC_NUMERIC) but didn't see anything. How do locale settings affect weak typing (specifically thinking string - float)? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Hi Zeev,
On Wed, Feb 18, 2015 at 2:31 PM, Zeev Suraski z...@zend.com wrote:
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and on
the
very first if it was a strict hint:
for ($i = 0; $i 11; $i++)
{
foo(base_convert($i, 10, 16));
}
And when I said leading zeros, I was talking about fixed-length string
identifiers such as '001', '002', etc. where you may *unintentionally*
pass
such a value to a function that deals with ... quantities, for example. A
strict
hint in that case would immediately catch this logical error while a weak
hint
would silently ignore the leading zeros and will happily treat the value
as an
integer. Again, the precondition here is that it's not an integer value
that
happens to be stored as a string, but a non-integer value that just looks
like
an integer.
Thanks the example Andrey, it's helpful.
My goal with asking for these use cases isn't to claim that they never
exist, and I certainly don't want to get into a theological discussion. My
goal is to try and figure out whether many, if not all, proponents of strict
typing would be willing to live with a compromise on single set of rules,
that on one hand would be a lot stricter than what was proposed for weak
typing in the v0.3 RFC (bool-anything fails, any string that's not strictly
looking like a number incl. 100 dogs - int/float fails, float-int
fails), but on the other hand, would allow certain lossless conversions
(numeric string - int/float, int-float, toString() to string, etc.) to
work.
I didn't imply that you meant any of that, not in this thread anyway
... If I've done it previously, it's only because your choice of words
had made it appear that way. You don't need to defend yourself
everytime I quote you. :)
When people from both schools of thought (strict/weak) come to evaluate this
possibility, remember that we don't need a solution that works in 100.0% of
the cases. Edge cases, again, be them strict or weak, can always be
implemented with a bit of custom code inside the function - the important
thing is to get a system that addresses the vast majority of cases.
Well, that's usually the case because you simply can't provide a 100% solution.
In this case, I believe we can satisfy if not 100%, then 99% of the
use cases by simply providing both weak and strict hints
simultaneously. From my POV, further restricting conversion rules for
weak hints is deffinately an improvement, but still a limited one.
There's no *technical* limitation to including two solutions to the
problem, so I'd rather do that and be practical instead of following a
belief for what does or doesn't belong in PHP.
I know you're on the flip side, so we shall agree to disagree on that.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Hi François,
On Wed, Feb 18, 2015 at 3:02 PM, François Laupretre franc...@php.net wrote:
De : Andrey Andreev [mailto:n...@devilix.net]
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and
on the very first if it was a strict hint:
for ($i = 0; $i 11; $i++)
{
foo(base_convert($i, 10, 16));
}
You're right. An hexa string with no leading '0x' and containing decimal
digits only cannot be recognized as hexa. But I keep thinking that, balancing
pros and cons, it's not enough to justify strict mode. Maybe I'm wrong and
additional use cases will make me change my mind, but I consider hexa with no
prefix as an edge-case.
I don't say that's the right solution but the problem can be solved at the
base_convert() level. If we support '0x' strings as hexadecimal numbers, it
can generate the '0x' prefix, which removes ambiguity for PHP and any other
software that would have to interpret the string. Unfortunately, it would
probably have to be explicitly required through an option because of BC. No
perfect solution here.
In real-world applications, base_covert() would hardly ever be the
culprit and I don't want to change its current behavior. I only used
base_convert() in the example because that allowed the least amount of
code written to display the problem.
Another argument some may consider weak : I'm also afraid that, in your
example, the user seeing an error raised by strict mode could change its code
to 'foo((int)base_convert', definitely hiding the real bug, even for 11 and
up. So, Rasmus is right when he says strict mode can sometimes and indirectly
be counter-productive. Debugging shouldn't be considered as error suppression
only, but it is the case more than often.
Sorry, but I do consider that to be a weak argument ... We can't help
users who's only concern is eliminating error messages, we can only
help those that understand them.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
Hi Michael,
The case of null is a little special.
As a type hint, we need it for return and union types only.
Considering union types, they were clearly left out of scope for 7.0 and I
personally won't propose pre-defined union types before the general case for
unions is designed. Conversion to union type, in particular, is complex, and
requires more thinking and discussion.
Hold on, usually, type checking functions don't identify NULL as scalar.
I don't understand your point as parameter parsing currently accepts null as
scalar (converting to 0 or empty string).
If you mean is_xxx() functions, that's irrelevant because these functions,
except a few ones like is_numeric(), are just based on zval type and don't
accept *any* conversion.
I profit of this mail to propose :
- disabling accepting null as number, string, or bool (it is already rejected
for other types).
- also disabling implicit conversions of any type to null (a function declared
to return int couldn't return null without adding 'null' to its return type,
which requires union types).
A consequence is that, until we have union types, a function returning int or
null, for instance, cannot have an explicit type.
It is important because disabling implicit conversion to null allows to trap
functions ending without an explicit 'return' statement, while supposed to
return a value.
Example:
Function foo(int $a): int
{
If ($a 0) return $a;
} - Error : received null while expecting int
While this will be OK when union types exist :
Function foo(int $a): int|null
{
If ($a 0) return $a;
}
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hints v0.4
De : Rowan Collins [mailto:rowan.coll...@gmail.com] That's precisely the case for every existing user-defined function. Switching to PHP 7 won't suddenly add type hints to every function in every library and every existing bespoke code base, so there is no way to avoid that thought process. I think the rules need to apply to everything or nothing. The rules will apply to everything in the same way - if a function is typehinted, it behaves like so; if it's not, it behaves the same way it did in PHP 5. I understand your pov but, in mine, there's no reason to artificially consider internal functions as untyped by adding another mostly-redundant mechanism for internal type hinting. If nothing existed, this would be fine, but if we split ZPP and type hinting info, we're creating a redundancy we'll pull behind us forever. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Hi Sara (and thanks for continuing the work!)
Le Tue Feb 17 2015 at 23:04:20, Sara Golemon poll...@php.net a écrit :
[...]
2) Define a way to enable strict mode (we'll be weak by default).
[...]
3) Tighten up coersion rules for weak mode. i.e. 10 dogs for an int
is a violation, but 10 is acceptable.
Regarding 2) and 3):
An option might be to implement weak mode only and configure the coercion
rules reporting in a similar way than with the error_reporting
configuration entry.
Not focusing on the details here, but I think about something like:
function foo(int $a) {
var_dump($a);
}
ini_set(coercion_reporting, 0); // current PHP 5.x behaviour
foo(7);
// int(7)
foo(7);
// int(7)
foo(7 dogs);
// int(7)
ini_set(coercion_reporting, COERCION_WARNING); // Warn, but do not
fail in case of potentially bad coercion
foo(7);
// int(7)
foo(7);
// int(7)
foo(7 dogs);
// Warning: Unsafe coercion transforming 7 dogs to 7.
// int(7)
ini_set(coercion_reporting, COERCION_ERROR); // Fail in case of
potentially bad coercion
foo(7);
// int(7)
foo(7);
// int(7)
foo(7 dogs);
// Catchable fatal error: Unsafe coercion transforming 7 dogs to 7.
The biggest advantage, IMHO, is that you get the exact same result whether
you do:
foo((int) $value);
or:
foo($value);
... whatever the mode you are in.
Basically, this is weak type hints + something similar to what I
contributed in the past with the Array to string conversion notice (see:
https://github.com/php/php-src/commit/d81ea16e).
Care to share the pro's/con's you see with a solution like that?
Thanks in advance.
Cheers,
Patrick
Re: [PHP-DEV] Scalar Type Hints v0.4
On 18/02/15 14:59, Pádraic Brady wrote: I wouldn't necessarily mind int-float - it's lossless assuming one way only. Assuming int is not 64 bit ;) -- 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
De : Leigh [mailto:lei...@gmail.com] Can we keep a 0) of reserve names for future use in-case of RFC failure option. Reserving names is only needed as long as we keep keywords sharing the same naming space as classes. This is a mistake from the past and, as long as we keep it, each new keyword is a pain. Reserving keywords in advance can only lead to reserving too few or too much. So, IMO, deprecating bare class names as hint is first. Then, we can reserve a limited set of keywords. How do you propose weak typing works with these? Does it only allow one of the union of types through (thus making it strict), or does it try and coerce to one if it can? Which one does it pick? That's exactly the problem we need to solve before going the union type road. A limited set can be implemented now as new zpp types, but none that requires questionable conversion (while useful, we are not ready for 'int|float', for example). Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
2015-02-18 12:45 GMT+01:00 Rowan Collins rowan.coll...@gmail.com: Michael Wallner wrote on 18/02/2015 11:39: On 18/02/15 12:31, Rowan Collins wrote: Michael Wallner wrote on 18/02/2015 11:19: On 17/02/15 23:03, Sara Golemon wrote: 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) Hold on, usually, type checking functions don't identify NULL as scalar. No need for anyone to hold on; as it says in the section you've quoted we can argue what's in this list separately. Sara's after reactions to the principle of having meta-types/unions in general, not their definitions, right now. Did you already incorporate strict mode yourself? SCNR I'm not a native speaker, so hold on might mean something different to you than to me. Sorry, what I meant was, don't worry, this isn't the kind of issue that we need to worry about yet. Sara's e-mail made clear that these were quick examples, and she wasn't expecting feedback on the details at this stage. Still, nullable types is something that had been proposed several times in this list, and fits nicely with the introduction of union-types. So, yes it would be nice null not to be included in scalars. Instead, we could have a union type like scalar? = scalar|null Lazare INEPOLOGLOU Ingénieur Logiciel Regards, -- Rowan Collins [IMSoP] -- 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 Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov dmi...@zend.com wrote: 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. I agree with Dmitry. Exporting the AST to userland in PHP 7.0 would be nice. With Dmitry's work on assertions we even have a pretty printer for it, which allows us to convert the AST back to PHP code. The bits about intercepting compilation, modifying the AST and importing it back into the compiler are a LOT more complicated. Apart from many open design questions, this will also require quite a bit of implementation effort because we must be very careful with the many assumptions the compiler makes about the structure of the AST (otherwise - segfaults). I'd prefer to delay this to a later PHP version (there's no problem to add it in a minor), preferably with a PoC extension being available beforehand. Alexander, I would recommend you to split this into two RFCs, one dealing only with AST export (and maybe pretty printing) and the second one with the compilation hooks. There's probably a few questions about the export API that should be discussed that will be forgotten if everyone focuses on the more complicated, and probably not yet relevant, question of compilation hooks. Nikita
