Re: [PHP-DEV] Only variables can be passed by reference
Hi Kalle,
Thank you for the list. It's very helpful!
On Fri, Dec 5, 2014 at 4:58 AM, Kalle Sommer Nielsen ka...@php.net wrote:
2014-12-04 9:28 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Any comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
I think we should solve these on a case-by-case basis, I can think of
one reason why the warning exists, and that is because it modifies the
array pointer and the argument is sent by reference. But I think we
can safely remove the warning if the parameter was not sent by
reference, as then we would expect the user to use the return value of
array_pop() to assign the value from. I don't think we should remove
warnings if you pass a statically value to it, sure some APIs can
return a variable length/dynamic array but then I think they should be
referenced into a variable and then passed to the function as they are
most likely going to be used later, I can't really think of a case
where it would be useful to send a return value of some API call to
array_multisort() and then use the boolean true or false to check if
it was a successful call for example..
For functions like next() that only supports taking the argument by
reference, this should remain (since the return value is the internal
array pointer position).
I went over the manual and the following should remain that warning:
array_multisort()
array_push()
array_shift()
array_unshift()
array_walk()
array_walk_recursive()
asort()
arsort()
each()
ksort()
krsort()
natsort()
natcasesort()
reset() -- Debatable though (does not many any sense, but if current()
and family is, and this is not, it will make it inconsistent)
rsort()
shuffle()
sort()
usort()
uasort()
uksort()
Agreed.
I would like to do like
$var;
array_walk(func(), function ($v, $k) use ($var) {
$var .= $v.$k;
});
though.
And the following can have the warning removed if the argument is not
passed by reference:
array_pop()
array_splice()
current() -- Debatable though
end() -- Debatable though (use array deferencing?)
extract()
key() -- Same as current()
next() -- Same as current()
prev() -- Same as current()
I think
array_pop()
array_splice()
extract()
These could be changed.
First of all, removing warnings only for these is feasible in PHP7?
We need Engine experts. Thank you.
Does anyone object to remove warnings for these?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Dragging the legacy users forward.
On 08/02/15 06:37, Yasuo Ohgaki wrote: Hi Lester, PHP7 is proposing a LOT of shiny new features which will break much legacy code. So the question has to be just what is the plan regarding cross version support. I see that the general consensus is PHP5 should just run? Do you mean release 5.7 or extend life of 5.6? I'm +1 for both options. Extending 5.6 life may achieved consensus. Perhaps, 2 year security support? Well I don't remember any such restriction on PHP4? Although there is still a compatibility library to emulate some later features where PHP4 did not provide them. But we are only talking about 'PHP4' being stable up to PHP5.2 and quoting periods here is irrelevant. Nobody is currently taking any notice of the fact HP5.2 and 5.3 are no longer supported and it's that the removal of features was badly managed that has created this problem. From a day to day survival point of view I have to decide what to do with currently functional sites that ARE still on PHP5.2 hosting. The bulk of the sites that have been moved to PHP5.4 still require regular work because people keep finding fault with one mobile device or another not displaying 'bootstrap3' properly which is another major upgrade path that is the MAIN reason for reworking sites and the one that prevents simple sticking plasters to hack PHP changes. I spent most of yesterday trying to get a key component of a financial site into a format that it could even be used on a mobile phone. And failed, so now I have to find another way to meet the LEGAL requirement that the customer has to comply with. So in general no I'm not talking about having to fix PHP5 code to some PHP7 compliant state, I AM talking about current PHP5 code simply working as PHP4 did into PHP5 hosting! CURRENTLY my php7 test site is running PHP5.4 live code so I don't think I'm out of line here, but if something goes in which causes my php7 test site to crash then I would prefer that to be sorted by PHP7 rather than having to upgrade to some as yet unavailable PHP5.x, although I would be more than happy if I can simply amend the live code and make both work. -- 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
[PHP-DEV] I declare declare to be useful... potentially...
Am 08.02.2015 03:39 schrieb Rasmus Lerdorf ras...@lerdorf.com: Basically declare() does not respect function scope, but it doesn't let you know that. There is a reason we haven't used declare() for anything real. That is absolutely awful. But it's a fault with declare. Can't that be fixed once and for all by fixing declare parsing - when used that way inside a function, make its scope end with the end of the function, as we would all have expected it to be, and as it would be when used in the declare-with-a-block-form? I chose a different subject, as it's an issue separate from the strict typing thing itself. declare is, to me, a very useful construct. Somebody recently wrote that it is just a localized version of ini settings. That's right - it's the way language (interpretation) settings SHOULD BE: give the power LOCALLY to the coder, with effects LOCALLY in the file and/or scope where it is used, and for the selective purpose given in the declare conditions. This is the ONLY sane way to make such switches. It does not magically make code fail when nonlocal stuff (ini settings) is changed, and it is more-locally reversible, in its block form, when needed. It is all about giving power to the calling code, which is a good thing with the potential to resolve several of the long standing discussions on this list. I applaud Andrea for having seen this, and followed through with it, regarding strict type checks. Other issues that may be solved in a similar way, using declare as a local behaviour switch, are: * scoped, stacked modifications to error handling: * overriding, for a while, the current global error handler * autoconversion of errors to exceptions * autoconversion of exceptions to errors * suppression of error output (without affecting handling itself) * assertions/pre/postconditions, as recently discussed in the DbC thread * an in-PHP alternative to #ifdeffery, for leaving out code fragments based on the presence or values of already defined constants. Something I'd love to have This would provide a nicer way for BC and FC handling code, and if declare could be made to pretty much ignore the detailled content of its block (except for curly brace matching), would even work out for reserved keyword issues. * a generic way to change ini settings with automatic resetting at the end of the declare block/scope. * a hook for extensions to introduce new declare conditions, with the extension getting, in AST form, the condition value, and a way to selectively operate on the declare block or rest-of-file AST. Apart from fixing the declare function scoping thing, a second modification might be needed in general, to go forward and backward with it afterwards: _ignore_ unknown declare conditions, with a safe semantic meaning of leaving out the block (or rest of file, in the nonblock form, a la __halt_compiler!) altogether. So there you have it, my vision of what poor mistreated declare could be. Do with it what you like. But I had to write it down... best regards Patrick
Re: [PHP-DEV] [RFC][DISCUSSION] Introduce scrpt_path
Hi Matthew,
On Sat, Feb 7, 2015 at 5:29 AM, Matthew Leverton lever...@gmail.com wrote:
On Fri, Feb 6, 2015 at 1:02 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Basically, it's administrative solution. Application should set these
setting
or administrator should.
Library shouldn't touch the setting, otherwise they hit their own foot.
If this was a PHP_INI_PERDIR setting, then I wouldn't really mind as much.
But as PHP_INI_USER, I don't like it at all.
How about allow to set the ini only once during execution?
To all, please give some feedback. There is option 5(Leave as it is), too!
I would like to know your preference. Multiple choices are OK ( +1 / -1 )
Comments are appreciated.
1. script_path INI. (Defines script path. Almost perfect solution with
upload_path INI) [1]
2. upload_path INI. (Exception path in script_path. Protection against
require('../../upload/evil');) [1]
3. require_embed INI (Enable/disable require()/require_once() embed(script
only) mode. Temp INI) [2]
4. script()/script_once() [3] (No INI switch. Read only scripts. The same
as require()/require_once(), require_embed=On )
5. Leave as it is now (No protection against file inclusion execution
attacks.)
[1] script_path defines script directory, upload_path defines exceptions
under script_path.
[2] require_embed is not described in current RFC. It's INI for
enable/disable script only mode.
require_embed should be REMOVED few years later.
[3] script/script_once is not described in current RFC. It read/execute
script only file.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sat, Feb 7, 2015 at 11:11 PM, Andrea Faulds a...@ajf.me wrote: Hi, On 7 Feb 2015, at 22:03, Pavel Kouřil pajou...@gmail.com wrote: Yeah, but you say in the RFC that With this approach, an argument is only accepted if its type is exactly the same as the parameter. when speaking about C# and Java - which is NOT true. C# and Java aren’t really considered weakly-typed. Technically they’re not “fully strict” I guess, but if you were to give example of strictly-typed languages, you’d probably include C# and Java in that list - so I did. C# and Java definitely aren't weakly typed. I never said they are though? Also, is there a real difference between strict and strong? Because C# refers to itself as a strongly typed, but you use strict typing everytime you speak about strong typing? It might be somewhat misleading. Really, what’s “weak” and what’s “strict” is rather subjective: C is sometimes considered weak, sometimes strict. I’d say it’s more “weak” because all sorts of definitely wrong conversions are allowed implicitly and merely generate warnings. C# and Java are more careful here, so I’d say they’re “strict” even though I suppose they do have a degree of weak typing. Also, there's no need to mention float - int, because that one is definitely wrong. But for the int (and long, etc) - float (and double) - how do the languages you mentioned in the RFC handle that conversion? From Microsoft’s documentation that you linked, it sounds like they just always convert and never error, so you’d get data loss in some cases (just like you do in PHP with an explicit cast). I am familiar with other languages, I just disagree with their approach. It's not somewhat misleading, it's 100% misleading - because you state that it acts like in Java and C#, but it doesn't. Also, are there any strongly typed language that implement strong/strict typing the way you want to do it in PHP? And as I said myself multiple times in the past, the declare syntax IS just ugly (and changing how code works by writing one line is an ugly principle as well, IMHO). :( I prefer this approach to the inconsistency the other approaches suggested thus far lead to. The thing is, you cannot please everyone. When you try to please anyone, you usally end up with something that has flaws for everyone to some degree. :( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sun, Feb 8, 2015 at 3:38 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/07/2015 05:03 PM, Pavel Kouřil wrote: I'm wishing more and more that the RFC doesn't pass (even though I'd LOVE to have typehints in PHP as a userland developer) and someone else will make a better version of typehints RFC for PHP 7, because this one feels really like you took an ok-ish RFC (one that would be good for PHP) and slapped a strict typing on it without enough research about strong typing in other languages. And as I said myself multiple times in the past, the declare syntax IS just ugly (and changing how code works by writing one line is an ugly principle as well, IMHO). :( I am not sure I would go that far. Andrea did plenty of research and has tons of experience in other languages, I just think this approach is misguided. I also wonder just how many people of those who voted even bothered to download and try the patch. I tried it a while back on some existing code and it was a nightmare. Does everyone realize that these simple things break? tan(1); echo strstr(test, est, 1); Seems like a case where one mans bug is another mans feature. While int-float conversions are debatable (and the answer may not be obvious if you consider bigints) I would definitely want the latter call to error. Seeing strstr(test, est, 1) I would obviously assume that 1 is an offset parameter, like it is the case with many other str* family functions. strstr(test, est, true) is a lot more obvious and I'll be happy if PHP yells at me if I'm sacrificing three keystrokes for a lot of readability. Basically declare() does not respect function scope, but it doesn't let you know that. There is a reason we haven't used declare() for anything real. This sounds like a bug more than anything else. It can be easily fixed. Nikita
Re: [PHP-DEV] Dragging the legacy users forward.
Lester Caine wrote in message news:54d73248.9030...@lsces.co.uk... On 08/02/15 06:37, Yasuo Ohgaki wrote: Hi Lester, PHP7 is proposing a LOT of shiny new features which will break much legacy code. So the question has to be just what is the plan regarding cross version support. I see that the general consensus is PHP5 should just run? Do you mean release 5.7 or extend life of 5.6? I'm +1 for both options. Extending 5.6 life may achieved consensus. Perhaps, 2 year security support? Well I don't remember any such restriction on PHP4? Although there is still a compatibility library to emulate some later features where PHP4 did not provide them. But we are only talking about 'PHP4' being stable up to PHP5.2 and quoting periods here is irrelevant. Nobody is currently taking any notice of the fact HP5.2 and 5.3 are no longer supported and it's that the removal of features was badly managed that has created this problem. From a day to day survival point of view I have to decide what to do with currently functional sites that ARE still on PHP5.2 hosting. The bulk of the sites that have been moved to PHP5.4 still require regular work because people keep finding fault with one mobile device or another not displaying 'bootstrap3' properly which is another major upgrade path that is the MAIN reason for reworking sites and the one that prevents simple sticking plasters to hack PHP changes. I spent most of yesterday trying to get a key component of a financial site into a format that it could even be used on a mobile phone. And failed, so now I have to find another way to meet the LEGAL requirement that the customer has to comply with. So in general no I'm not talking about having to fix PHP5 code to some PHP7 compliant state, I AM talking about current PHP5 code simply working as PHP4 did into PHP5 hosting! CURRENTLY my php7 test site is running PHP5.4 live code so I don't think I'm out of line here, but if something goes in which causes my php7 test site to crash then I would prefer that to be sorted by PHP7 rather than having to upgrade to some as yet unavailable PHP5.x, although I would be more than happy if I can simply amend the live code and make both work. Well said. If it is not possible to have a single codebase that runs in both PHP 5 *AND* PHP 7 then that will be a total disaster. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] [VOTE] Parameter skipping RFC
Hi! I'd like to announce a vote on parameter skipping RFC: https://wiki.php.net/rfc/skipparams TLDR: it allows using default to specify that parameter has the default value when calling function with optional parameter, like this: create_query(deleted=0, name, default, /*report_errors*/ true) The implementation is mostly finished, there may be some things needed for merging etc. or small improvements, but I'd like to have a vote on general concept first. The vote is straight yes/no vote, and closes in 2 weeks from now. Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Design by Contract
Hi Guilherme and Francois,
Could you give your ideas for these?
Thank you.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sun, Feb 8, 2015 at 5:16 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dimitry, Francois and Guilherme,
On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Yasuo,
Following our conversation, I tried to imagine how DbC should look like
in PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
requre(input-assert-expression)
ensure(output-assert-expression)
{
...
}
It would require only one new reserved word ensure.
Should I add D like version to the RFC? I don't care much about syntax as
long as
we have DbC.
https://wiki.php.net/rfc/dbc
Like Guilherme suggested, make some decisions first?
1- Doc comments vs. outside?
2- Keep object instance creation the same? IE: @Foo vs new Foo()
3- Is constructor the only way to inject parameters?
4- What if we have optional arguments, like: @Foo(bar, null, null,
woo)?
Suppose that you wanna fix the optional arguments by declaring names (like
this: @Foo(bar, test=woo)), doesn't it collide with PHP interests of
not supporting parametrized arguments? How would parameter skipping
proposal address this in a nicer way?
5- How would you deal with inheritance? Should a method inherit the same
annotations from parent or not?
Should we add ability to flag to inherit or not? What about overrides?
Would they be allowed? Is there a vague idea on how this concept could be
achieved?
6- Would you be possible to change annotations value at runtime?
7- Would we validate annotation arguments at all? Consider as array?
Properties of objects?
8- In case we take the approach of properties of objects... how would we
flag that a given class can/cannot be used as annotation: another
annotation, interface, any other idea?
9- Would we and/or wow would we flag that a given class could be used only
in a class and not in a method?
10- How would it be the syntax to declare a new annotation?
Since people's preferences are diverse. It might be a good idea having
pre-vote
for designs, then we may have final vote with single design.
We need some consensuses even for pre-vote.
What do you think?
Guilherme, is this the RFC you've mentioned?
Whenever you feel ready to get true, complete Annotations into core
https://wiki.php.net/rfc/annotations
Just making sure.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Re: Design by Contract
Hi Dimitry, Francois and Guilherme,
On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Yasuo,
Following our conversation, I tried to imagine how DbC should look like in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
requre(input-assert-expression)
ensure(output-assert-expression)
{
...
}
It would require only one new reserved word ensure.
Should I add D like version to the RFC? I don't care much about syntax as
long as
we have DbC.
https://wiki.php.net/rfc/dbc
Like Guilherme suggested, make some decisions first?
1- Doc comments vs. outside?
2- Keep object instance creation the same? IE: @Foo vs new Foo()
3- Is constructor the only way to inject parameters?
4- What if we have optional arguments, like: @Foo(bar, null, null, woo)?
Suppose that you wanna fix the optional arguments by declaring names (like
this: @Foo(bar, test=woo)), doesn't it collide with PHP interests of
not supporting parametrized arguments? How would parameter skipping
proposal address this in a nicer way?
5- How would you deal with inheritance? Should a method inherit the same
annotations from parent or not?
Should we add ability to flag to inherit or not? What about overrides?
Would they be allowed? Is there a vague idea on how this concept could be
achieved?
6- Would you be possible to change annotations value at runtime?
7- Would we validate annotation arguments at all? Consider as array?
Properties of objects?
8- In case we take the approach of properties of objects... how would we
flag that a given class can/cannot be used as annotation: another
annotation, interface, any other idea?
9- Would we and/or wow would we flag that a given class could be used only
in a class and not in a method?
10- How would it be the syntax to declare a new annotation?
Since people's preferences are diverse. It might be a good idea having
pre-vote
for designs, then we may have final vote with single design.
We need some consensuses even for pre-vote.
What do you think?
Guilherme, is this the RFC you've mentioned?
Whenever you feel ready to get true, complete Annotations into core
https://wiki.php.net/rfc/annotations
Just making sure.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Reserving primitive types
Hello everyone, I've been following the Static type hints discussion for a while now. Aside from its content, which there are some strong sentiments about, there's also another recurring pattern - the wish for voting options instead of just yes/no. Along these lines I've created an RFC on one aspect of primitive type hinting (whether parameters or return type), namely reserving the primitive type names: https://wiki.php.net/rfc/reserve_primitives I personally see the benefits this could have but also the BC break this would introduce. Let me know whether it's worthwhile putting this up for discussion. I'm happy to add, elaborate or remove options as a result of feedback before doing so. Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserving primitive types
Hi Timm, On 8 Feb 2015, at 12:04, Timm Friebe p...@thekid.de wrote: Hello everyone, I've been following the Static type hints discussion for a while now. Presumably you mean scalar not static. Aside from its content, which there are some strong sentiments about, there's also another recurring pattern - the wish for voting options instead of just yes/no. Along these lines I've created an RFC on one aspect of primitive type hinting (whether parameters or return type), namely reserving the primitive type names: https://wiki.php.net/rfc/reserve_primitives I personally see the benefits this could have but also the BC break this would introduce. Let me know whether it's worthwhile putting this up for discussion. I'm happy to add, elaborate or remove options as a result of feedback before doing so. I don't see the point of this: the Scalar Type Hints RFC already has a voting option on reserving the type names, and it is set to pass, so by the time your RFC could go to a vote, it would have been rendered redundant. Thanks. -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] Dragging the legacy users forward.
Hi Lester, On 07.02.2015 13:36, Lester Caine wrote: My personal experience of PHP4 is simply one of having been developing all my code in PHP5.0 to 5.2 but ensuring that the code also still run clean on the PHP4 host. Actually, PHP 4 changed a lot of things from PHP3. PHP 5.0.0 on the other hand allowed you to run much legacy code while providing new and better solutions to many problems. PHP 5 lasted about 10 years and the later half of its life cycle actually amounted to pulling in new features which should have gone into some PHP 6 while keeping an aging core afloat on new hardware, new platforms. 32-bit is essentially dead, Itanium is long forgotten for most applications, Arm and x86_64 are standard. In a perfect world, php 5 wouldn't have lasted that long and a lot of userland code would have broken years ago, requiring trivial changes. It was not until 5.3 that it was necessary to freeze the code base for 5.2 for every PHP4 host and maintain that fork while 'taking advantage' of the new features of PHP5 that were not supported by PHP4. That is the code base that is currently populating the vast majority of PHP powered sites still, so while PHP4 is dead it's footprint still lives on. A lot of sites sticked with PHP5.3 because they were driven by enterprise platforms which by definition won't upgrade during the life cycle. That had its own costs and aches which are entirely not PHP's fault. PHP7 is proposing a LOT of shiny new features which will break much legacy code. Which features hurt you? Which features break code which would have been best practice by php 5.0.0? But do we have to start taking greater care of third party libraries which as with the 5.2 to 5.4 switch means that two versions are needed? I've currently deliberately configured my development system so that PHP5 and PHP7 are running the same code set and once I have all the missing extensions I can start playing further, but I need to work out how to allow 'needs PHP7' libraries in parallel. Are you talking about userland code or extensions here? Which php5 best practice feature would be broken by php 7? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Reserving primitive types
Hi, I personally see the benefits this could have but also the BC break this would introduce. [...] I don't see the point of this: the Scalar Type Hints RFC already has a voting option on reserving the type names, and it is set to pass, so by the time your RFC could go to a vote, it would have been rendered redundant. My point is to prevent adoption hurdles *before* PHP 7's release. PHP 5 was a sad story in regard to this. PHP 7 shouldn't be; and doesn't have to: So far, PHP 7 has stayed largely BC-break free, which is good for its adoption. I believe more than just yes and no should be considered in this case, which breaks existing code - not just in edge cases and in near-bug-scenarios. Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] [VOTE] Scalar Type Hints
-Ursprüngliche Nachricht- Von: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Gesendet: Sonntag, 8. Februar 2015 04:53 An: Andrea Faulds Cc: Pavel Kouřil; PHP Internals Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints On 02/07/2015 09:51 PM, Andrea Faulds wrote: tan(1); echo strstr(test, est, 1); Banning int-float and float-int is both a pain point and sometimes a life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you discover if your ints floats would be silently truncated (as I did with PictoSwap). I wouldn’t say that int-string not working is a problem, though. Seeing something like strstr(“test”, “est”, 1); is rather confusing. Looking at it, I’d think the third parameter is some sort of number for you to want to pass an integer to it. If I want a string, I’ll use one. This isn't int-string. This is int-boolean. The 3rd arg to strstr() is a boolean and passing 1 instead of true makes it blow up. It is very very common for people to pass 0 or 1 in place of true/false to all sorts of things in PHP. Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one sense (like encoding, but unlike ticks, it has no effect on the including or included files). However, it technically affects the remainder of the file, not the whole file. Well, no, not the remainder of the file either since it can be switched again. It only affects the part of the file between declares if there is a second one. -Rasmus I think that it is a perfect example why strict typing has its merits. It is funny to see how confusing it seems to be that you passed 1 instead true but anyway... I already mentioned once that we could handle number literals as different types depending on its context (like Haskell does it). For instance: sin(1) is perfectly fine as well, since 1 is an integer literal and can be used as float literal as well. I would only allow int - float but not int - bool (see confusion above). Cheers, Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dragging the legacy users forward.
On 08/02/2015 11:24, Tony Marston wrote: Well said. If it is not possible to have a single codebase that runs in both PHP 5 *AND* PHP 7 then that will be a total disaster. Of course you can have a single codebase running both on PHP5 and PHP7, unless you want to use PHP7-only features. But that doesn't mean that any codebase that currently runs on PHP5 will keep working on PHP7 without any changes. Most of the modern codebases probably will though. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dragging the legacy users forward.
On 08/02/15 11:43, Ralf Lang wrote: A lot of sites sticked with PHP5.3 because they were driven by enterprise platforms which by definition won't upgrade during the life cycle. That had its own costs and aches which are entirely not PHP's fault. PHP7 is proposing a LOT of shiny new features which will break much legacy code. Which features hurt you? Which features break code which would have been best practice by php 5.0.0? Currently it is impossible to run the PHP5.2 code base on PHP5.4. That is a simple fact. So I can't do between 5.2 and 5.4 what I am currently doing between 5.4 and 7. The code has to be reworked ... so what ever anybody says PHP5 .4 *IS* PHP6 in terms of major breaks. 'Best Practice' is at best dependent on just what style of working a particular faction wants. Is 'strict typing' an example of future best practice? Is e_strict compliant code best practice? It is that which I base the move from 5.2 to 5.4 on. If I add a library using namespaces often things fail to work so I stick with the 'non-namespace' version? Best practice these days is I suppose to be using composer for everything? None of this was around by 5.0.0 days yet the bulk of my framework code is well over 10 years old and at one time one could select you preferred database install and run. Nowadays just keeping a small subset of database engines working is all we can manage. PHP is no longer the simple user friendly base that it once was! -- 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] Security changes in PHP 7
Hi Leigh, On 2/8/15, 12:33 PM, Leigh lei...@gmail.com wrote: Are we happy to accept that we'll lose access to some of mcrypts ciphers if we do this? I'd suspect most real world usage of php-mcrypt is to implement AES anyway, so most users would be covered. I hope your suspicion is right. I'd be happy to lose all but AES and Blowfish cyphers and CBC and CTR modes. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 07/02/2015 01:08, Sebastian Bergmann wrote: On 02/06/2015 10:22 PM, Nikita Popov wrote: After much initial reluctance, I've voted in favor of this RFC. After reading your email, Nikita, I deleted my vote (it was no before). I will review the RFC again, with your arguments (and others) in mind and maybe I'll come to a different conclusion. Thank you for that, Sebastian. It is not a simple RFC and votes should be thought through as it is such an old and important topic to many people. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dragging the legacy users forward.
On 08/02/2015 11:45, Matteo Beccati wrote: On 08/02/2015 11:24, Tony Marston wrote: Well said. If it is not possible to have a single codebase that runs in both PHP 5 *AND* PHP 7 then that will be a total disaster. Of course you can have a single codebase running both on PHP5 and PHP7, unless you want to use PHP7-only features. It may be true right now, but it is not inevitable. There are certain behaviour or syntax changes that could, theoretically, require the same feature to be written differently in the two versions. Luckily, such changes are rare, and are usually spotted and avoided (as with the change to DateTime typehinting mentioned recently), but it's not something that goes without saying. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Security changes in PHP 7
On 8 February 2015 at 17:03, Pierre Joye pierre@gmail.com wrote: I agree with Derick about wrapping ext/mcrypt around OpenSSL or other to keep it around for BC. I simply do not have the resources to make that happen so someone has to jump on it (Derick?) Are we happy to accept that we'll lose access to some of mcrypts ciphers if we do this? I'd suspect most real world usage of php-mcrypt is to implement AES anyway, so most users would be covered. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Security changes in PHP 7
On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster f...@thefsb.org wrote: Thanks Damien and Daniel for the info. I am not concerned about running out of entropy. I am concerned about userspace RNGs such as OpenSSL http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ Just to be clear (as Damien also mentioned): openssl is not a userspace RNG. It uses the underlying system-specific resources. If your system's RNG is good enough (/dev/[u]random in nix-like systems) for you, openssl_random_pseudo_bytes() is good enough for you.
Re: [PHP-DEV] Annotated PHP 5-7 extension diff
On Thu, Feb 5, 2015 at 10:41 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: My biggest concern about all this breakage done for NG could somehow be minimized by providing possible alternate implementations that could work both backwards compatible and forwards compatible? I just don't want to work on extensions I support that would never be usable in earlier versions once finished the update. Hi, I have create a header that does it ( see https://github.com/bukka/phpc/blob/master/phpc.h ). There are still quite a few bits that need to be added and tidied up but it already suppors most cases that I will need in my extension. The header probably doesn't show much (and might look a bit scary ... :) ) so I have created a testing ext that uses it. You can see the result here: https://github.com/bukka/php-extest/blob/master/extest_compat.c As you can see there isn't a single ifdef and it compiles and works (test passes) for PHP 7 and 5 (tested on 5.6 but should be fine for 5.2+). It means that it won't require any changes in PECL. There isn't much documentation as yet because I'm still working on it. But I plan to add it later. Any comments or patches are welcome! Cheers Jakub
Re: [PHP-DEV] Dragging the legacy users forward.
On 08/02/2015 12:30, Lester Caine wrote:
Currently it is impossible to run the PHP5.2 code base on PHP5.4. That
is a simple fact. So I can't do between 5.2 and 5.4 what I am currently
doing between 5.4 and 7. The code has to be reworked ... so what ever
anybody says PHP5 .4*IS* PHP6 in terms of major breaks.
We have a single code base happily running on 5.2, 5.3, 5.4, and I think
even 5.5, so it is definitely possible with some code bases. There were
a few pieces that had to be changed to work right under 5.3 and 5.4, but
none for which the new solution didn't also work under 5.2 (or, at
least, for which a compromise didn't exist which worked under both).
Call-time pass-by-reference was all over the place, for instance, but
rarely actually needed, and if it was, replacing it with a
pass-by-reference declaration would leave you with something working
fine under 5.2.
It's frustrating not being able to use new features when you need to
support an outdated installation, and finding third-party libraries
which support old versions of PHP can be tricky. 5.3 was the big
breaking point there, because although we didn't refactor our code to
use namespaces, libraries quickly came to be written with them (which is
a good thing) so automatically have that as a minimum version requirement.
The biggest problem with keeping userland code cross-version compatible
is usually syntax - behaviours and standard functions can, if it's
really necessary, be worked around by checking PHP_VERSION, or if ( !
function_exists('blah') { function blah { ... } }. But because there's
no equivalent of a C pre-processor, you can't work around syntax which
wasn't valid on older versions, other than by not using it (it would
have been lovely to include closures in code which was simply
unreachable on 5.2 hosts, but if 5.2 needed to parse that file, it was
impossible).
Clearly, your experience is different; perhaps some specific examples of
the problems which forced you to fork the codebase, rather than adapt it
into a cross-compatible state, would help people look out for the same
situation arising in future.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Security changes in PHP 7
On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster f...@thefsb.org wrote: 3. Will the OpenSSL ext remain as it currently stands? There has been talk of replacing it with a more generic implementation that can swap out the underlying components so we aren't dependent upon a single library. The crypto extension in pecl is working on such an approach, but AFAIK it's not yet stable. That said, ext/openssl already delegates to Windows API functions to provide equivalent functionality as needed, so this is already happening to some extent. Additionally, for better or worse ext/openssl is tightly integrated into the current streams implementation when crypto is required (i.e. the ssl stream wrapper). Any new solution would need to provide equivalent functionality. 4. What does openssl_random_pseudo_bytes() really do in PHP? It's less about what it does in PHP and more about what it does in the openssl lib itself with the exception being Windows environments. ### In Windows This function delegates to CryptGenRandom() which uses the general system-wide RNG. It *is* possible for an application to add its own data to the further randomize the internal seed, however, the current openssl_random_pseudo_bytes() does not expose this capability to userland. ### Elsewhere Openssl transparently seeds its entropy pool. Once the pool has been seeded with enough data it will always have sufficient data to ensure an unpredictable byte sequence is returned. So it now becomes a matter of whether or not it has enough entropy at the time of your call to openssl_random_pseudo_bytes(). Openssl actually exposes two separate APIs for this case, so let me explain what each does: - RAND_bytes() Always return an error if there is insufficient data in the pool to ensure unpredictability. - RAND_pseudo_bytes() Always return bytes, even if the entropy pool has not been sufficiently seeded. Currently PHP's openssl_random_pseudo_bytes() uses the latter function and allows users to pass a by-reference $crypto_strong out parameter to determine if the result is cryptographically strong. This is fine if you know all of the above and have read the manual for this function. However, it may be desirable to add a new openssl_rand_bytes() function that uses RAND_bytes() under the hood to make it less likely for someone to accidentally use insufficiently random output. I don't think there would be an analog to this functionality in Windows as the documentation for CryptGenRandom() makes no mention of when/if this API can return a sequence of bytes that is not cryptographically secure. So, a new openssl_random_bytes() might only amount to an alias of the existing openssl_random_pseudo_bytes() function in this environment. Please provide feedback if you think a new function should be added as this is a relatively straightforward thing to do. I would also like to propose a new optional $additionalSeed string parameter that could be passed from userland to include in the entropy pool since both the underlying Windows and Openssl APIs support this functionality. Feature Freeze for PHP 7 is coming soon. I, for one, would value a summary of what's happening in PHP 7 with respect to security topics like but not limited to these. FYI I still plan to add both client-side and server-side support for OCSP verification in encrypted streams. The other thing I plan to do is add support for the (relatively new) TLSALPN extension in encrypted client/server streams. This extension is required to establish encrypted connections using the forthcoming h2 (HTTP/2.0) protocol.
Re: [PHP-DEV] Remove mycrypt. Vote ends Monday
Tom Worster f...@thefsb.org schreef op 8 februari 2015 15:38:15 GMT+00:00: mycrypt was abandoned by its developers in 2007. The package in Debian is from 2009. It has been removed from RHEL. This is already unacceptable. But it would be an insult to the idea of security to include mcrypt in PHP 7. The vote to remove mcrypt is at present tied roughly 13:13. If you have a vote and haven't used it yet, I urge you to consider doing so. Voting ends tomorrow 2015-02-09 at 23:00 CET https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extmcrypt Btw, I only voted no because I don't think we should just remove it. A reimplementation of its APIs on top of eg. Open SSL makes sense. And that I'd vote yes for. Calling for a random deletion is misguided. Remember that just removing quite often used APIs doesn't help anybody. It is not unlikely that devs would rather rip out the encryption as a quick fix, than porting it to quite awful other APIs, or perhaps even a really slow PHP based implementation. cheers, Derick - mcrypt extension author -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Security changes in PHP 7
On Sun, Feb 8, 2015 at 5:15 PM, Daniel Lowrey rdlow...@php.net wrote: Currently PHP's openssl_random_pseudo_bytes() uses the latter function and allows users to pass a by-reference $crypto_strong out parameter to determine if the result is cryptographically strong. This is fine if you know all of the above and have read the manual for this function. However, it may be desirable to add a new openssl_rand_bytes() function that uses RAND_bytes() under the hood to make it less likely for someone to accidentally use insufficiently random output. Hi Daniel, Just to clarify: OpenSSL automatically seeds its random pool from crypto-safe system-specific sources (/dev/[u]random on Linux): it is just *impossible* on modern systems to end up in the case of not having enough entropy. Damien
Re: [PHP-DEV] Security changes in PHP 7
On Feb 8, 2015 10:44 PM, Tom Worster f...@thefsb.org wrote: Hi Yasuo, Pierre, Thank you both for the updates. I expect the vote to remove mcrypt can be shifted towards yes if some campaigning effort is made. I made a start in another thread. Assuming that mcrypt goes, as it should, we are left with a problem. I agree with Derick about wrapping ext/mcrypt around OpenSSL or other to keep it around for BC. I simply do not have the resources to make that happen so someone has to jump on it (Derick?) Cheers Pierre
Re: [PHP-DEV] Remove mycrypt. Vote ends Monday
Hi Derick, On 2/8/15, 11:38 AM, Derick Rethans der...@php.net wrote: Btw, I only voted no because I don't think we should just remove it. A reimplementation of its APIs on top of eg. Open SSL makes sense. And that I'd vote yes for. This idea makes me nervous. It doesn't sound at all easy and will take a lot of time and effort. Commitment to maintaining a security lib over long term is a big deal. Remember that just removing quite often used APIs doesn't help anybody. It is not unlikely that devs would rather rip out the encryption as a quick fix, than porting it to quite awful other APIs, or perhaps even a really slow PHP based implementation. I actually think that it helps users if PHP 7 moves mycrypt to PECL. The developers' quick fix is to continue to use mcrypt. In doing so they should encounter the documentation with scary warning about its long abandoned status. I'm concerned that a lot of devs relying on mcrypt are not aware of its status and/or what it means. This move would allow them to continue to use mcrypt while making it clear that its time to plan for an alternative. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Security changes in PHP 7
Thanks Damien and Daniel for the info. I am not concerned about running out of entropy. I am concerned about userspace RNGs such as OpenSSL http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ On 2/8/15, 12:04 PM, Damien Tournoud d...@damz.org wrote: On Sun, Feb 8, 2015 at 5:15 PM, Daniel Lowrey rdlow...@php.net wrote: Currently PHP's openssl_random_pseudo_bytes() uses the latter function and allows users to pass a by-reference $crypto_strong out parameter to determine if the result is cryptographically strong. This is fine if you know all of the above and have read the manual for this function. However, it may be desirable to add a new openssl_rand_bytes() function that uses RAND_bytes() under the hood to make it less likely for someone to accidentally use insufficiently random output. Hi Daniel, Just to clarify: OpenSSL automatically seeds its random pool from crypto-safe system-specific sources (/dev/[u]random on Linux): it is just *impossible* on modern systems to end up in the case of not having enough entropy. Damien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Security changes in PHP 7
Hi Yasuo, Pierre, Thank you both for the updates. I expect the vote to remove mcrypt can be shifted towards yes if some campaigning effort is made. I made a start in another thread. Assuming that mcrypt goes, as it should, we are left with a problem. The PHP user doesn't have a platform-independent way to get pseudo-random bytes for crypto. OpenSSL's RNG is not to be trusted. If the user knows this (I wouldn't bet on it) then she has to resort to accessing the platform RNG directly. On Unix-like system's it is technically easy but much confusion is caused by the Linux man page with its myth that urandom is unsafe for crypto. On Windows I just have no idea how the user might proceed. So I really think the Reliable, userfriendly RNG APIs idea in the wiki is very important. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Remove mycrypt. Vote ends Monday
mycrypt was abandoned by its developers in 2007. The package in Debian is from 2009. It has been removed from RHEL. This is already unacceptable. But it would be an insult to the idea of security to include mcrypt in PHP 7. The vote to remove mcrypt is at present tied roughly 13:13. If you have a vote and haven't used it yet, I urge you to consider doing so. Voting ends tomorrow 2015-02-09 at 23:00 CET https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extmcrypt
[PHP-DEV] RE: Design by Contract
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki Since people's preferences are diverse. It might be a good idea having pre-vote for designs, then we may have final vote with single design. We need some consensuses even for pre-vote. What do you think? What I think is that I have written a 600-line RFC, that you refuse to comment because you still hope you can impose a D-like syntax by another way. I don't agree on a pre-vote on design and, then, care about details, because that's just an artefact to get an agreement on D-like syntax before people can read and understand my proposal, and without exploring the implications of your design. Here is a fair way to proceed: I have written an RFC, trying to explore honestly every aspects of the design I'm proposing. Now, either you agree, or you write yours with the same goal in mind. Then, we may choose. That's the rule. Saying 'I don't like that' without proposing an alternative is not the right way. I won't help you get an a-priori approval, just to say thereafter that, whatever problem we find, we must stick with this design because it was pre-approved. If you write an RFC and people approve it, that's OK. Anyway, as I think DbC can be implemented without any change in the core, I'll probably implement it by myself as a zend extension. So, you can do what you want in PHP 7. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserving primitive types
Hi Timm 2015-02-08 13:04 GMT+01:00 Timm Friebe p...@thekid.de: Hello everyone, I've been following the Static type hints discussion for a while now. Aside from its content, which there are some strong sentiments about, there's also another recurring pattern - the wish for voting options instead of just yes/no. Along these lines I've created an RFC on one aspect of primitive type hinting (whether parameters or return type), namely reserving the primitive type names: https://wiki.php.net/rfc/reserve_primitives You forgot to add 'real' to the list (its a float). -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserving primitive types
Hi, On 8 Feb 2015, at 13:32, Timm Friebe p...@thekid.de wrote: I personally see the benefits this could have but also the BC break this would introduce. [...] I don't see the point of this: the Scalar Type Hints RFC already has a voting option on reserving the type names, and it is set to pass, so by the time your RFC could go to a vote, it would have been rendered redundant. My point is to prevent adoption hurdles *before* PHP 7's release. PHP 5 was a sad story in regard to this. PHP 7 shouldn't be; and doesn't have to: So far, PHP 7 has stayed largely BC-break free, which is good for its adoption. If this RFC would somehow pass, yes. However, you’re introducing a competing proposal at the “eleventh hour”, so to speak, which is terribly nice. Unless there’s a radical shift in how people vote on the Scalar Type Hints RFC, it won’t pass, anyway. I believe more than just yes and no should be considered in this case, which breaks existing code - not just in edge cases and in near-bug-scenarios. This has been discussed extensively in the Scalar Type Hints RFC thread, but people have voted to reserve the type names anyway. I appreciate your concerns, but introducing a competing RFC *while its competitor is in voting* is both poor sportsmanship, and quite probably futile. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserving primitive types
On 8 Feb 2015, at 15:48, Andrea Faulds a...@ajf.me wrote: If this RFC would somehow pass, yes. However, you’re introducing a competing proposal at the “eleventh hour”, so to speak, which is terribly nice. Unless there’s a radical shift in how people vote on the Scalar Type Hints RFC, it won’t pass, anyway. Sorry, I meant “isn’t terribly nice”. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
De : Jordi Boggiano [mailto:j.boggi...@seld.be] Envoyé : dimanche 8 février 2015 19:12 À : internals@lists.php.net Objet : Re: [PHP-DEV] [VOTE] Scalar Type Hints On 07/02/2015 01:08, Sebastian Bergmann wrote: On 02/06/2015 10:22 PM, Nikita Popov wrote: After much initial reluctance, I've voted in favor of this RFC. After reading your email, Nikita, I deleted my vote (it was no before). I will review the RFC again, with your arguments (and others) in mind and maybe I'll come to a different conclusion. Thank you for that, Sebastian. It is not a simple RFC and votes should be thought through as it is such an old and important topic to many people. Please send congratulations in private mails. You really don't have the sense of the ridiculous. Why don't you offer money to people to change their vote ? (just kidding but, just in case...) Do you remember that the overall objective is CONSENSUS. As Zeev already said, the only result of your insistence was to split the community into two polarized camps. Do you think we have too many people working on PHP internals ? As a consequence of the PHP 6 failure, we lost several among the most precious ones. Do you want to do the same with PHP 7 ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sun, Feb 8, 2015 at 1:48 PM, Zeev Suraski z...@zend.com wrote: proposal everyone can rally behind, it very clearly failed. We didn't have to wait for a vote by the way, it was clear from the discussion on internals@. Controversial RFCs are precisely the ones that SHOULD be voted on. Policy states that 2/3s means consensus on core language changes. The current 63.5% isn't too far from that. Just curious, but do you have a different number in mind for this vote? 90%? 80%? -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
-Original Message- From: Matthew Leverton [mailto:lever...@gmail.com] Sent: Sunday, February 08, 2015 11:17 PM To: Zeev Suraski Cc: Jordi Boggiano; PHP internals Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints On Sun, Feb 8, 2015 at 1:48 PM, Zeev Suraski z...@zend.com wrote: proposal everyone can rally behind, it very clearly failed. We didn't have to wait for a vote by the way, it was clear from the discussion on internals@. Controversial RFCs are precisely the ones that SHOULD be voted on. Not really. These should be avoided as much as possible. Policy states that 2/3s means consensus on core language changes. The current 63.5% isn't too far from that. Just curious, but do you have a different number in mind for this vote? 90%? 80%? I'm well aware of it as I wrote that policy. The goal of the policy was to prevent a situation where a temporary majority can introduce features into the language that would later on be impossible to reverse. It's not by any stretch a good mechanism to solve controversial votes, which again, should ideally be avoided as much as possible. It's just that there isn't a better mechanism. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] scalar type hints
Hello, First of all, thank you for php. Secondly, I hope this doesn't come across as impertinent. I'm an average user of php. I don't know enough about programming languages to contribute here; but I do try and keep up with what's going on in the php core. I was curious what the userland view of scalar type hints was, so I set up a two question SurveyMonkey poll asking about the current RFC. To be clear, I don't think php should be a democracy; I am not intending to somehow subvert the RFC process. As I see it, you all have rather difficult judgements to make about the language, and those decisions may have far-reaching consequences. But I do wonder if 'what do php users think' might be a useful additional data point for you when making those judgements. The first question was 'Did you read the RFC' and the second 'Would you like the RFC to pass'. I set it up Friday morning (GMT) and tweeted it around a bit (I have a grand total of 58 followers on twitter). So this relates to version 0.3 As of now, 306 people have responded, a lot more than I anticipated. 84% said they read the RFC; 83% would like it to pass (full responses here: https://www.surveymonkey.com/results/SM-Q8KRRZV7/, the survey itself here: https://www.surveymonkey.com/s/SDB2V6Z). I hope this is helpful. [About the survey]. Settings on Survey Monkey were: randomised order of answers to Q2; one response only. I tweeted it, and @ tweeted a few people that I noticed talking about the RFC. I think it got forwarded on a bit. Possible problems with it: 1. Not enough responses / it's not representative? - I'd be happy if others with more prominent twitter presences (let's face it, that's not hard) wanted to publicise it. Although if it goes over 1000 responses I'd have to stump up a load more cash to SurveyMonkey, so I hope 1000 would be enough ;) 2. It doesn't contain any information. Everyone knows we all want scalar type hints, but a similar result would have been gained with a completely different approach. The problem isn't whether to, it's how best to, and it's unlikely that those polled understand the trade-offs. - Possibly. Again, I'm surprised by the number of responses, and the numbers both reading the RFC and wanting it. To me, the strongest message is 'please get something into php 7'. Watching all this from the outside, I worry that this will not be the outcome. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 artifact - binary strings
Hi, On 8 Feb 2015, at 21:48, Marc Bennewitz dev@mabe.berlin wrote: Wrapping all in objects isn't an option. This would only add unnecessary overhead and only move the issue to a different place. I don’t see why not. Objects are generally exempt from type juggling, except for conversion to strings. Surely that’s what you want? This would break existing code which was made “PHP 6-ready”. I don't think so. If a string was declared as binary it should be binary else it is a wrong declaration and a bug. It already is binary, though. PHP’s strings are binary, they always have been. The reason that we have (binary) is because PHP 6 was going to make (string) a synonym of (unicode) instead. Also, we already support bitwise operations on strings, I don’t know what you’re on about there... Sorry I wasn't clear. I mean the bitwise shift operators see http://3v4l.org/MBadR That would be a BC break, and the kind of non-obvious evil one Derick doesn’t like much. Though I can’t talk: I already ‘broke’ bitwise shifts with the Integer Semantics RFC. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I declare declare to be useful... potentially...
On 08/02/2015 09:20, Patrick Schaaf wrote:
Am 08.02.2015 03:39 schrieb Rasmus Lerdorf ras...@lerdorf.com:
Basically declare() does not respect function scope, but it doesn't let
you know that. There is a reason we haven't used declare() for anything
real.
That is absolutely awful. But it's a fault with declare. Can't that be
fixed once and for all by fixing declare parsing - when used that way
inside a function, make its scope end with the end of the function, as we
would all have expected it to be, and as it would be when used in the
declare-with-a-block-form?
I chose a different subject, as it's an issue separate from the strict
typing thing itself.
declare is, to me, a very useful construct. Somebody recently wrote that it
is just a localized version of ini settings. That's right - it's the way
language (interpretation) settings SHOULD BE: give the power LOCALLY to the
coder, with effects LOCALLY in the file and/or scope where it is used, and
for the selective purpose given in the declare conditions. This is the ONLY
sane way to make such switches. It does not magically make code fail when
nonlocal stuff (ini settings) is changed, and it is more-locally
reversible, in its block form, when needed.
It is all about giving power to the calling code, which is a good thing
with the potential to resolve several of the long standing discussions on
this list. I applaud Andrea for having seen this, and followed through with
it, regarding strict type checks. Other issues that may be solved in a
similar way, using declare as a local behaviour switch, are:
* scoped, stacked modifications to error handling:
* overriding, for a while, the current global error handler
* autoconversion of errors to exceptions
* autoconversion of exceptions to errors
* suppression of error output (without affecting handling itself)
* assertions/pre/postconditions, as recently discussed in the DbC thread
* an in-PHP alternative to #ifdeffery, for leaving out code fragments based
on the presence or values of already defined constants. Something I'd love
to have This would provide a nicer way for BC and FC handling code, and
if declare could be made to pretty much ignore the detailled content of its
block (except for curly brace matching), would even work out for reserved
keyword issues.
* a generic way to change ini settings with automatic resetting at the end
of the declare block/scope.
* a hook for extensions to introduce new declare conditions, with the
extension getting, in AST form, the condition value, and a way to
selectively operate on the declare block or rest-of-file AST.
So there you have it, my vision of what poor mistreated declare could be.
Do with it what you like.
But I had to write it down...
I agree with pretty much everything in this post.
While it is messy to have a language with too many runtime behaviours,
it's much more useful to have them explicitly and lexically scoped than
to have them either global or dnyamically toggled at runtime, which are
the options ini settings have now. The problem, I guess, is in how you
implement it - does the declare directive have to cause the compiler to
emit different opcodes for this file, or does it require extra code to
run on every entry and exit.
For instance, this would be really useful to wrap around legacy code
that is being phased out rather than improved:
declare(error_handling=E_WARNING|E_ERROR) {
function foo() { ... }
function bar() { ... }
}
The only way I can think to implement that is to add opcodes to the
beginning and end of each function to push and pop the setting each time
the code is called - the low-level equivalent of $old_eh =
error_reporting(E_WARNING|E_ERROR); ... error_reporting($old_eh); I
don't know how much overhead that would incur in practice; presumably
unlike @ it wouldn't defeat optimisations, since the start of a function
definition is always a boundary to that kind of thing anyway?
Apart from fixing the declare function scoping thing, a second modification
might be needed in general, to go forward and backward with it afterwards:
_ignore_ unknown declare conditions, with a safe semantic meaning of
leaving out the block (or rest of file, in the nonblock form, a la
__halt_compiler!) altogether.
I think it's a shame that declare() itself wasn't always implemented
with forwards-compatibility in mind. In some cases (probably including
strict types) the declaration itself could be completely ignored, rather
than causing the file to be parsed as empty (which is probably no more
useful than it emitting a parse error). I wonder if it's feasible to
write extensions for *old* versions of PHP which add new declare()
directives?
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] Introduce scrpt_path
On 08/02/2015 09:03, Yasuo Ohgaki wrote:
If this was a PHP_INI_PERDIR setting, then I wouldn't really mind as much.
But as PHP_INI_USER, I don't like it at all.
How about allow to set the ini only once during execution?
Like open_baedir [1], it should probably be possible to *tighten* the
settings, but never *loosen* them. So, you could remove items from
script_path, or alter them to be more specific; or you could add them to
upload_path, or alter them to be more general.
The relationship to open_basedir should perhaps be more explicit - for
instance, your example of require('/etc/passwd') is better handled by
open_basedir, which also prevents readfile('/etc/passwd').
A file path should ideally be evaluated against 3 tests:
A) should this file be accessible, and readable? (controllable through
open_basedir; should be a pre-requisite for B and C)
B) should this file be writable? (currently left to OS level protection)
C) should this file be executable as PHP code? (should apply through
include()/require(), and also if passed as a direct argument to the PHP
SAPI; the latter part is currently left to the web server configuration,
while the first part cannot be controlled at all)
Even with all of these, there are still vulnerabilities, just ones which
require multiple steps, e.g.:
- for any file in (A), read its contents into memory, and trick the
application into executing it from a string
- find an intersection between (B) and (C), such as a compiled template
cache, and inject a string from user input, or a file in (A), which will
then be executed
[1]: http://php.net/manual/en/ini.core.php#ini.open-basedir
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP6 artifact - binary strings
Hi all, Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can define binary strings but such definitions haven't any effect. So what we can define is the following: $str = str; $bin = bb\0i\0n; $str2bin = (binary)$str; One of the biggest issue is that currently ALL strings will be handled as ASCII-7 compatible strings on type-juggling but they aren't. It would be very appreciated if PHP could respect such binary declaration: * use binary string comparison on compare a binary string to any other string * don't convert binary strings into integers on array keys * allow bitwise operators on binary strings without casting to integer I don't wont to open such unicode nightmare as it was planned for PHP-6! In my opinion the above operator changes are enough and therefore internal functions doesn't need to be changed in the first place. The only changes *could* be done to functions reading/parsing data to be auto marked binary like: unpack, stream reading functions opened with fopen + b ... I don't have enough zend experience and therefore I would like to know how complicated it would be. Thoughts? Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(), which
was definitely not intended for this purpose.
Zeev
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, February 08, 2015 9:45 PM
To: PHP Internals
Subject: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
Hi,
I’m posting this in a new thread since people might (reasonably) be
ignoring
further responses to the [VOTE] thread.
I’m considering a small change to the Scalar Type Hints RFC, specifically
about syntax. Quite a few people have said they don’t like the declare()
syntax, and it’s easy to see why. It’s rather verbose, it has all the
quirks of
declare() (such as block syntax, not respecting scope), and it’s rather
ugly.
Instead, I’m wondering if the following might be better:
?php strict
Which would be used like so:
?php strict
function foobar(): int {
return 1.0; // error!
}
It’d be a per-file directive, so there’d be zero mixing of modes within
one file,
and you’d avoid the quirks of declare().
It’s also a lot shorter, and it resembles Hack’s syntax:
?hh // strict
Of course, changing this would mean restarting the vote, but it’s only
been
three days, we’re less than a quarter of the way through voting.
Thoughts? Thanks!
(By the way, I’d appreciate it if this thread didn’t turn into yet another
discussion of how and whether scalar type hints are a bad/good idea. We
already have at least four threads on that subject. I’m just considering a
specific change of syntax.)
--
Andrea Faulds
http://ajf.me/
--
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] Re: Security changes in PHP 7
On Sun, Feb 8, 2015 at 2:18 PM, Tom Worster f...@thefsb.org wrote: On 2/8/15, 12:52 PM, Daniel Lowrey rdlow...@php.net wrote: On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster f...@thefsb.org wrote: Thanks Damien and Daniel for the info. I am not concerned about running out of entropy. I am concerned about userspace RNGs such as OpenSSL http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ Just to be clear (as Damien also mentioned): openssl is not a userspace RNG. OpenSSL has an RNG that is not in the kernel memory space. Software that is in memory but not in the kernel space is in the user space. You're right, my mistake. I don't claim to be a crypto expert in any sense of the word -- I simply implement APIs that real crypto experts create. I don't believe it makes any sense for us to implement this in php-src directly. If you haven't compiled openssl with a different RNG engine it's going to default to use RAND_SSLeay(). The explanation here explains the logic involved: https://www.openssl.org/docs/crypto/rand.html#internals Dr. Henson is far smarter than I am; I'll take his word for it. The only outstanding issue noted in the linked discussion is An initial source of random 'state' which, as you can see by reading the subsequent RAND_add() documentation is transparently retrieved from /dev/urandom for us: On systems that provide /dev/urandom, the randomness device is used to seed the PRNG transparently. However, on all other systems, the application is responsible for seeding the PRNG by calling RAND_add() If you're in Windows this is handled by a different API. And if not, I tend to trust the openssl PRNG since it pulls its initial random state from /dev/urandom. I honestly don't see the problem here. I'm happy to be wrong if someone says, no, we should come up with a different way to do this, and can provide logic to back that up. Personally, I have no reason to believe the openssl implementation is inadequate. We could add the ability to pass in your own initialization data but the only good option there is pulling it from `fread()` on /dev/urandom anyway ... a somewhat pointless exercise as openssl already does this.
Re: [PHP-DEV] Dragging the legacy users forward.
On 08/02/15 19:00, Rowan Collins wrote: We have a single code base happily running on 5.2, 5.3, 5.4, and I think even 5.5, so it is definitely possible with some code bases. There were a few pieces that had to be changed to work right under 5.3 and 5.4, but none for which the new solution didn't also work under 5.2 (or, at least, for which a compromise didn't exist which worked under both). Call-time pass-by-reference was all over the place, for instance, but rarely actually needed, and if it was, replacing it with a pass-by-reference declaration would leave you with something working fine under 5.2. Rewriting the the code to make it work is exactly what is taking the time, but I DID also adopt the standard that e_strict would be required and up until that time all the code I was involved with ran with display_errors ON which was a conscious choice to pick up problems that crept in when they happened rather than having to trawl through hundreds of log files every few days. Remove 'register_globals' and a site breaks until such time as the code is reworked, but that code also needs to be brought up to a better standard rather than simply hacking the register_globals and other removed or backwards incompatible problems. Since a large part of the code I am now supporting I did not write, simply trying to decipher some of the strange tricks coders used to get up to is a nightmare, and some of the new 'styles' of writing things are going to make things considerably worse for those who are going to have to maintain this code in the future. There are several pages of things that were good practice in PHP5.0 code which will now give white screens if one tries to run them on a 'good practice' PHP5.4 setup. Fortunately I think that I've already covered most of the later problems in trying to make the legacy code clean e_strict code so switching from 5.4 to 5.6 should not cause a problem, but I'm not ready to move production beyond 5.4 as yet. If I was only worried about a couple of sites then things would be different, but the current catalogue is some 120 different sites some of which are pigging ASP and I will be glad when I can finally pull them over to PHP. -- 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] Syntactical change to Scalar Type Hints RFC
Hi François,
On 8 Feb 2015, at 20:43, François Laupretre franc...@tekwire.net wrote:
De : Andrea Faulds [mailto:a...@ajf.me]
Instead, I’m wondering if the following might be better:
?php strict
Which would be used like so:
?php strict
function foobar(): int {
return 1.0; // error!
}
It’d be a per-file directive, so there’d be zero mixing of modes within one
file, and you’d avoid the quirks of declare().
'?php' is not a 'per-file' directive, as it can appear several times, and is
not always the first item in a file.
What would this mean :
Lines of data
...
?php
php code
?
Data
?php strict
Code
...
Would it be strict or not ? or will you interpret the first '?php' only ?
What is the syntax exactly ? Does it make 'strict' a reserved keyword ?
It doesn't make strict be reserved.
With regards to multiple blocks, there are a few possible approaches:
* First block affects subsequent blocks, only it can declare strictness (my
favourite)
* Per-block
* Use of directive prevents use of end tags, and thus use of multiple blocks
I think the first makes the most sense. It's what namespaces do, after all.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Security changes in PHP 7
On 2/8/15, 12:52 PM, Daniel Lowrey rdlow...@php.net wrote: On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster f...@thefsb.org wrote: Thanks Damien and Daniel for the info. I am not concerned about running out of entropy. I am concerned about userspace RNGs such as OpenSSL http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ Just to be clear (as Damien also mentioned): openssl is not a userspace RNG. OpenSSL has an RNG that is not in the kernel memory space. Software that is in memory but not in the kernel space is in the user space. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Syntactical change to Scalar Type Hints RFC
Hi,
I’m posting this in a new thread since people might (reasonably) be ignoring
further responses to the [VOTE] thread.
I’m considering a small change to the Scalar Type Hints RFC, specifically about
syntax. Quite a few people have said they don’t like the declare() syntax, and
it’s easy to see why. It’s rather verbose, it has all the quirks of declare()
(such as block syntax, not respecting scope), and it’s rather ugly.
Instead, I’m wondering if the following might be better:
?php strict
Which would be used like so:
?php strict
function foobar(): int {
return 1.0; // error!
}
It’d be a per-file directive, so there’d be zero mixing of modes within one
file, and you’d avoid the quirks of declare().
It’s also a lot shorter, and it resembles Hack’s syntax:
?hh // strict
Of course, changing this would mean restarting the vote, but it’s only been
three days, we’re less than a quarter of the way through voting.
Thoughts? Thanks!
(By the way, I’d appreciate it if this thread didn’t turn into yet another
discussion of how and whether scalar type hints are a bad/good idea. We already
have at least four threads on that subject. I’m just considering a specific
change of syntax.)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Zeev, On 8 Feb 2015, at 19:48, Zeev Suraski z...@zend.com wrote: Last, voters should take into account that this isn't an 'either this RFC or nothing' situation. I think it's very unfortunate that the original RFC - that had zero controversy surrounding it - was never put to a vote. Please stop repeating this, it is blatantly false and I’ve pointed this out several times. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
-Original Message- From: Jordi Boggiano [mailto:j.boggi...@seld.be] Sent: Sunday, February 08, 2015 8:12 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints On 07/02/2015 01:08, Sebastian Bergmann wrote: On 02/06/2015 10:22 PM, Nikita Popov wrote: After much initial reluctance, I've voted in favor of this RFC. After reading your email, Nikita, I deleted my vote (it was no before). I will review the RFC again, with your arguments (and others) in mind and maybe I'll come to a different conclusion. Thank you for that, Sebastian. It is not a simple RFC and votes should be thought through as it is such an old and important topic to many people. Indeed it is. I think it's very clear that this RFC represents (almost) the farthest possible position from consensus, with all of the original key designers of the language strictly opposing it, as well as many others. This is one of the most polarizing votes I ever recall here. I'm not sure whether it'll get through or not, but given the intention of this RFC was to create a proposal everyone can rally behind, it very clearly failed. We didn't have to wait for a vote by the way, it was clear from the discussion on internals@. I sincerely hope that we'll gather enough votes to prevent strict typing from making it into PHP. Last, voters should take into account that this isn't an 'either this RFC or nothing' situation. I think it's very unfortunate that the original RFC - that had zero controversy surrounding it - was never put to a vote. Clearly, it didn't give the strict camp what it wanted, but on the other hand, it introduced nothing into the language that anybody considers damaging to PHP - even in the eyes of the strict camp. That cannot be said about this RFC. I'm not sure how many of the people who support the current RFC would be equally happy (or happier) with the original one, but I suspect that it's a fair number, and we'd definitely want to put it to a vote in case the current one fails to pass (and potentially even if it does pass, to give people the opportunity to choose between having the extra strict part vs. not having it, a choice they didn't get but should have). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Scalar Type Hints
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Sunday, February 08, 2015 9:50 PM To: Zeev Suraski Cc: Jordi Boggiano; internals@lists.php.net Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints Zeev, On 8 Feb 2015, at 19:48, Zeev Suraski z...@zend.com wrote: Last, voters should take into account that this isn't an 'either this RFC or nothing' situation. I think it's very unfortunate that the original RFC - that had zero controversy surrounding it - was never put to a vote. Please stop repeating this, it is blatantly false and I’ve pointed this out several times. It's not blatantly false, and please refrain from telling me what I can or cannot say (!) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
De : Andrea Faulds [mailto:a...@ajf.me]
Instead, I’m wondering if the following might be better:
?php strict
Which would be used like so:
?php strict
function foobar(): int {
return 1.0; // error!
}
It’d be a per-file directive, so there’d be zero mixing of modes within one
file, and you’d avoid the quirks of declare().
'?php' is not a 'per-file' directive, as it can appear several times, and is
not always the first item in a file.
What would this mean :
Lines of data
...
?php
php code
?
Data
?php strict
Code
...
Would it be strict or not ? or will you interpret the first '?php' only ? What
is the syntax exactly ? Does it make 'strict' a reserved keyword ?
I am sorry but, IMO, it adds ambiguity to declare()'s ugliness.
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Annotated PHP 5-7 extension diff
Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported. We have UPGRADING.INTERNALS which still needs some
love, but even if that covered everything it is sometimes hard to match
a bullet point in a long list of changes to actual code.
UPGRADING.INTERNALS is far from complete. Take for instance the
substantial changes in zend_hash_index_find(_ptr). Look at
PHP_FUNCTION(dba_list) in dba.c. In PHP 5.6 that is
if (zend_hash_index_find(EG(regular_list), i, (void **) le)==FAILURE)
{
continue;
}
PHP7:
if ((le = zend_hash_index_find_ptr(EG(regular_list), i)) == NULL) {
continue;
}
You'll have to use another macro, with a different number of arguments
and a different false test. There is nothing in UPGRADING.INTERNALS on
this. The info on this change can be found in the Wiki:
https://wiki.php.net/phpng-upgrading
But the wiki on its turn is not complete either. For instance it still
mentions
ZEND_FETCH_RESOURCE2(ib_link, ibase_db_link *, link_arg, link_id,
LE_LINK, le_link, le_plink);
Since the API cleanup interbase does not compile anymore. The reason is
that the API cleanup brought substantial changes in
ZEND_FETCH_RESOURCE2. I guess this command now must be something like
ib_link = (ibase_db_link *)zend_fetch_resource2(Z_RES_P(link_arg),
link_id, LE_LINK, le_link, le_plink);
But this is only an educated guess based on looking at changes in other
extensions. At the moment I am struggling with the PHP7 translation of
this block:
#define GET_MOVIE_RESOURCE(ff_movie_ctx) {\
zval **_tmp_zval;\
if (zend_hash_find(Z_OBJPROP_P(getThis()), ffmpeg_movie,\
sizeof(ffmpeg_movie), (void **)_tmp_zval) == FAILURE) {\
zend_error(E_WARNING, Invalid ffmpeg_movie object);\
RETURN_FALSE;\
}\
\
ZEND_FETCH_RESOURCE2(ff_movie_ctx, ff_movie_context*, _tmp_zval, -1,\
ffmpeg_movie, le_ffmpeg_movie, le_ffmpeg_pmovie);\
}\
I have tried a lot of things, but nothing works so far...
An annotated diff would be very welcome! But more or less complete
documentation as well.
Jan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 artifact - binary strings
Hi, On 8 Feb 2015, at 20:10, Marc Bennewitz dev@mabe.berlin wrote: Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can define binary strings but such definitions haven't any effect. Yes. That’s because PHP 6 was going to have Unicode strings by default, alongside binary strings (to PHP 5 and 7, just “strings”). These “binary strings” are just strings. So what we can define is the following: $str = str; $bin = bb\0i\0n; $str2bin = (binary)$str; One of the biggest issue is that currently ALL strings will be handled as ASCII-7 compatible strings on type-juggling but they aren’t. In the rare case you need to prevent type juggling of binary data, you could wrap it in an object. It would be very appreciated if PHP could respect such binary declaration: * use binary string comparison on compare a binary string to any other string * don't convert binary strings into integers on array keys * allow bitwise operators on binary strings without casting to integer This would break existing code which was made “PHP 6-ready”. Also, we already support bitwise operations on strings, I don’t know what you’re on about there... -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds a...@ajf.me wrote: Good evening, At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them. I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences). Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints Thank you for your time. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, I've voted no for two reasons: 1, I don't really like the the proposed declare solution, I know that you put much thought and effort with finding a way to make the strict hints opt-in for the caller, but I think it is still not a good compromise: people in favor of strict hints will hate it because it is opt-in from the caller, so they can't use scalar hints to save the boilerplate for argument validation, and other people like me will unlike it because they think that the blockless declare will cause many errors and debugging headache when somebody moves some code between files (or concatenating files as part of their deployment process). 2, As this is a really polarizing topic I would like if the eventual solution would have wider support from the current php-src regular contributors, and not just pushed through by force. (And I know that status quo sucks when somebody trying to do innovative stuff, but it is a safe thing to default to). Thanks for your efforts on such a hard topic and I hope you can eventually succeed where everyone else failed thus far! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Managing builds via Eclipse
Does anybody have a working Eclipse setup for building php-src and extensions? I keep hitting 'phpsrc' when I try using google which just about sums up how bad google is these days :( As soon as one tries to drill down all one gets is pages with php in the url ... -- 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] Re: [RFC] [DISCUSSION] pecl_http
Hi! Are you saying performance is not the reason we use persistent handles? It is, for databases where connection setup is expensive. Even then persistent handles are not always the best solution. But with DB, you routinely connect to one service, with one set of credentials, and need this connection constantly. With HTTP, it is rarely the case that you want to maintain the connection to the same service for an extended time (like hours or even days). Stas, I really don't understand what's the issue here for you. The issue is that I think maintaining long-time persistent HTTP connections (I do not mean keepalive connection that serves a number of requests within the context of one workload, like browser does) is not a good idea, in fact it looks suspiciously like a DOS since many HTTP servers, including Apache, are not equipped properly to handle such model. While there may be corner cases where it may be useful, encouraging the practice looks like a mistake to me. Youself said that HTTP is a stateless protocol, so how would a connection in an unclean state look like in your opinion? Connection and protocol are different things. In connection, you could be in the middle of the protocol - i.e. sending headers, sending body, receiving headers, receiving body - and these are different states. Curl caches connections the servers are fine with keeping alive, and I cache curl handles grouped by the id you pass to the client constructor and the authority of the url, that's all, nothing spooky. Caching connections within the same request and reusing them is not spooky, but caching them long term, across requests, across security domains, for extended time - is spooky. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Ferenc, On 8 Feb 2015, at 22:18, Ferenc Kovacs tyr...@gmail.com wrote: I've voted no for two reasons: 1, I don't really like the the proposed declare solution, I know that you put much thought and effort with finding a way to make the strict hints opt-in for the caller, but I think it is still not a good compromise: people in favor of strict hints will hate it because it is opt-in from the caller, so they can't use scalar hints to save the boilerplate for argument validation Hmm. Personally, I don’t think types are really a substitute for argument validation. This doesn’t provide a means to force strict types upon people who don’t want them, sure… but the proposal is designed precisely to prevent that, since I don’t see someone like Zeev (say) wanting to deal with strict types any time soon. , and other people like me will unlike it because they think that the blockless declare will cause many errors and debugging headache when somebody moves some code between files (or concatenating files as part of their deployment process). It’s worth noting that I intend to change this to have the “?php strict” syntax rather than declare(). That’ll have to be a subsequent RFC, as I don’t want to cancel the vote. But it looks like it will pass since all the feedback I’ve got about that so far has been positive. 2, As this is a really polarizing topic I would like if the eventual solution would have wider support from the current php-src regular contributors, and not just pushed through by force. (And I know that status quo sucks when somebody trying to do innovative stuff, but it is a safe thing to default to). I’m not sure. There are some people completely opposed to compromise, that can’t be helped. For everyone else, I’m not sure how I feel about contentious votes. If it gets through by a 2/3 majority then presumably it does have significant support, though I worry about lasting impact. Votes do, at least, provide a way to resolve contentious issues, though. Thanks for your efforts on such a hard topic and I hope you can eventually succeed where everyone else failed thus far! Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP
Hi internals.
I really hope that in the future PHP 7, there will be new server API.
May be you interested to know about them, here is the link, I am not
the author of development:
https://github.com/unbit/uwsgi-phpsgi/
But the problem is that in PHP there are no standards for such interfaces.
Now it is implemented like this:
?php
function application($env)
{
return ['200 OK', ['Content-Type' = 'text/plain'], 'Hello, world!'];
}
?
I think this is a good opportunity to review the old interface ($_GET,
$_POST, ...) and start using the API internal HTTP module.
This all breaks backward compatibility, not $_GET, $_POST, ...
But this WSGI SAPI will used only new PHP code (not PHP legacy base).
This is a good opportunity to create something new and not be backward
compatible.
What do you think about this?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Design by Contract
Hi Francois, On Mon, Feb 9, 2015 at 12:43 AM, François Laupretre franc...@tekwire.net wrote: De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki Since people's preferences are diverse. It might be a good idea having pre-vote for designs, then we may have final vote with single design. We need some consensuses even for pre-vote. What do you think? What I think is that I have written a 600-line RFC, that you refuse to comment because you still hope you can impose a D-like syntax by another way. I don't agree on a pre-vote on design and, then, care about details, because that's just an artefact to get an agreement on D-like syntax before people can read and understand my proposal, and without exploring the implications of your design. Here is a fair way to proceed: I have written an RFC, trying to explore honestly every aspects of the design I'm proposing. Now, either you agree, or you write yours with the same goal in mind. Then, we may choose. That's the rule. Saying 'I don't like that' without proposing an alternative is not the right way. I won't help you get an a-priori approval, just to say thereafter that, whatever problem we find, we must stick with this design because it was pre-approved. If you write an RFC and people approve it, that's OK. Anyway, as I think DbC can be implemented without any change in the core, I'll probably implement it by myself as a zend extension. So, you can do what you want in PHP 7. I agree. I can also implement basic DbC feature as zend extension. It will be ugly without parser modification, but the change wouldn't be too hard. I'm sure Dmitry would do much better job than me :) You would like me to write D like version. No problem at all. If majority/consensus is annotation approach, I don't insist to have D like proposal. If you would like to choose by vote anyway, I'll write/add RFC with Dmitry's idea in mind. Dmitry, what is your opinion now? It's not mandatory, but I still prefer to have D like syntax because users can code contracts just like PHP code and get all kinds of syntax errors/etc as PHP. Would you like to have D like syntax as vote option or choose with one of annotation/D like before vote? (It seems annotation is more popular) D like design has advantage that internal functions/classes may have contracts just like user space. This may help to get better performance also. User would get consistent/similar contract errors from internal classes/functions. (I can imagine number of people against raising E_WARNING from classes, though) Guiherme, you have comprehensive annotation implementation. Could you give us your idea's about DbC and annotation? Is your idea the same as Francois's? https://wiki.php.net/rfc/dbc We don't have much time. I hope we have consensus before deadline. Thank you. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi! Last, voters should take into account that this isn't an 'either this RFC or nothing' situation. I think it's very unfortunate that the original RFC - that had zero controversy surrounding it - was never put to a vote. Please stop repeating this, it is blatantly false and I’ve pointed this out several times. How is it false? Did we have a vote on v1? What was the result of the vote? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, On 8 Feb 2015, at 23:03, Stanislav Malyshev smalys...@gmail.com wrote: Last, voters should take into account that this isn't an 'either this RFC or nothing' situation. I think it's very unfortunate that the original RFC - that had zero controversy surrounding it - was never put to a vote. Please stop repeating this, it is blatantly false and I’ve pointed this out several times. How is it false? Did we have a vote on v1? What was the result of the vote? No, we didn’t. But the statement “zero controversy” implies that, well… let’s look up what controversy means: argument that involves many people who strongly disagree about something : strong disagreement about something among a large group of people (Merriam-Webster) So, controversy is where a lot of people disagree - and there were numerous people in the original thread who disagreed with the RFC and preferred strict types. I actually tallied them in a reply to Zeev (which I later quoted in a reply to Andi). There were almost as many people against the proposal as in favour. This is to say nothing as to how it was received outside internals which, from my experience on reddit, Twitter and StackOverflow, was even less positive than internals, considerably so. So, I think that to say that there was “zero controversy” is certainly stretching the truth. Really, I’m yet to see any scalar type hinting discussions which haven’t had some controversy. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi!
Following our conversation, I tried to imagine how DbC should look like in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
requre(input-assert-expression)
ensure(output-assert-expression)
{
...
}
Why not do it simpler?
function foo() {
// require
assert(input-assert-expression);
...
// ensure
assert(output-assert-expression);
}
I'm oversimplifying a bit, but in general, why we need more places to
have code in the function than the actual code of the function? It would
be harder to parse, to read, to maintain, to debug, to profile, etc. and
I'm not sure what exactly it provides that can't be done by plain
regular code inside the function.
If we're concerned about the costs of assert, we could make special
provision in the compiler for zero-cost asserts. It doesn't require
moving code out of the function.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP
On 08/02/2015 22:48, S.A.N wrote:
Hi internals.
I really hope that in the future PHP 7, there will be new server API.
May be you interested to know about them, here is the link, I am not
the author of development:
https://github.com/unbit/uwsgi-phpsgi/
But the problem is that in PHP there are no standards for such interfaces.
Now it is implemented like this:
?php
function application($env)
{
return ['200 OK', ['Content-Type' = 'text/plain'], 'Hello, world!'];
}
?
I think this is a good opportunity to review the old interface ($_GET,
$_POST, ...) and start using the API internal HTTP module.
This all breaks backward compatibility, not $_GET, $_POST, ...
But this WSGI SAPI will used only new PHP code (not PHP legacy base).
This is a good opportunity to create something new and not be backward
compatible.
What do you think about this?
The problem with creating an event-based API for PHP is that you don't
just have to rethink superglobals, you have to rethink absolutely
everything that currently acts as global state:
- global variables
- static variables within functions
- class static variables
- dynamic settings (ini_set etc)
- globally registered callbacks (set_error_handler,
spl_autoload_register, etc)
- the counters of include_once() and require_once()
- any function which implicitly fetches data based on some previous
action (e.g. libxml_get_errors)
If the language is not itself multi-threaded, all of these become
arbitrarily shared once per thread the server spins up and reuses. If it
*is* multi-threaded, you have another set of headaches about how both
the engine and the userland can share and synchronize.
Not that I don't like the idea, but it's a huge project, with potential
for profoundly affecting the language.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dragging the legacy users forward.
On 08/02/2015 20:53, Lester Caine wrote: On 08/02/15 19:00, Rowan Collins wrote: We have a single code base happily running on 5.2, 5.3, 5.4, and I think even 5.5, so it is definitely possible with some code bases. There were a few pieces that had to be changed to work right under 5.3 and 5.4, but none for which the new solution didn't also work under 5.2 (or, at least, for which a compromise didn't exist which worked under both). Call-time pass-by-reference was all over the place, for instance, but rarely actually needed, and if it was, replacing it with a pass-by-reference declaration would leave you with something working fine under 5.2. Rewriting the the code to make it work is exactly what is taking the time, but I DID also adopt the standard that e_strict would be required OK, so that's your choice - you have deliberately set yourself a higher bar than PHP has, in order to end up with better code. Good for you. I can also imagine that setting that high bar may make it harder to make the kind of compromises that are inevitable when writing code intended to run on multiple versions simultaneously. Remove 'register_globals' and a site breaks until such time as the code is reworked, but that code also needs to be brought up to a better standard rather than simply hacking the register_globals and other removed or backwards incompatible problems. If all you're worried about is running on multiple versions of PHP, the manual includes a one-liner to emulate register_globals. Again, reworking it is a good idea, but not something that PHP actually forces on you. Some of the new 'styles' of writing things are going to make things considerably worse for those who are going to have to maintain this code in the future. If you're writing code that you know will be hard to maintain in the future, you're doing something wrong. If by slavishly following a style guide you've ended up with a poor architecture, you need a better style guide, or a better understanding of why those styles are preferred. Alternatively, I may have misunderstood that sentence, in which case I apologise in advance. There are several pages of things that were good practice in PHP5.0 code which will now give white screens if one tries to run them on a 'good practice' PHP5.4 setup. Maybe, but most of them can be replaced by code which runs fine on both versions. It may not be the best code you could write if you knew you could rely on new features, but it works. For instance, when the preg_replace /e modifier is removed, it will still be possible to write code that uses preg_replace_callback() with the almost-as-ugly create_function() instead of a real anonymous function. That gives you compatibility all the way back to 5.0, and all the way forward to 7.0; it's also slightly less likely to be a security hole, so you're improving your code base by doing it. If you decide that good code is more important than cross-compatibility, you can go ahead and use the 5.3+ closure syntax instead, but no decision made on this list will have forced that on you. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
On Mon, Feb 9, 2015 at 6:30 AM, Rowan Collins rowan.coll...@gmail.com wrote: On 08/02/2015 20:33, Zeev Suraski wrote: FWIW, while I think strict types - stricter than even strict languages - don't belong in PHP, this syntax is clearly a step up from declare(), which was definitely not intended for this purpose. I'm kind of intrigued what purpose it *was* intended for. I've always found it a rather odd part of the language, but this seems as logical a use for it as any. For years, it had exactly one execution directive, which worked in concert with a runtime event handler (ticks=N + register_tick_function). In PHP 5.3, a completely unrelated directive was added, to specify the encoding of the file (something that more obviously has to be detected by the compiler). Was there an original idea of what it would be used for that never came to fruition? Or is there something I'm missing that connects ticks and encoding, but excludes strict_types? Both are being done at compile time and modify how a file is compiled. So no, I do not agree with runtime here, while one directive is being used at runtime. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi Stas,
On Mon, Feb 9, 2015 at 8:11 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Following our conversation, I tried to imagine how DbC should look like
in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
requre(input-assert-expression)
ensure(output-assert-expression)
{
...
}
Why not do it simpler?
function foo() {
// require
assert(input-assert-expression);
...
// ensure
assert(output-assert-expression);
}
I'm oversimplifying a bit, but in general, why we need more places to
have code in the function than the actual code of the function? It would
be harder to parse, to read, to maintain, to debug, to profile, etc. and
I'm not sure what exactly it provides that can't be done by plain
regular code inside the function.
If we're concerned about the costs of assert, we could make special
provision in the compiler for zero-cost asserts. It doesn't require
moving code out of the function.
Interesting idea. I like it.
The only draw back I can see now is that this may make post/pre condition
retrieving
harder for automatic documentation. We may think of solution for this.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP
2015-02-09 2:26 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
On 09/02/2015 00:02, S.A.N wrote:
You're right, but there is no threading issues.
One worker synchronously execute requests, but may run parallel many
workers.
I'm not sure what you mean by this. I can see 3 ways of handling incoming
web requests, as it affects PHP's threading:
A) The current shared nothing model: the web server may have multiple
processes or threads, but each requested is executed in a completely
separate global scope of PHP.
B) Each process or thread in the web server spawns an instance of the
application; the application has a global state within that instance, and
startup and shutdown code; the instance is sent multiple requests, but has
no way to know if it is getting all the requests, half the requests, or one
hundredth of the requests.
C) The web server executes the application once, which sets up its global
state, and then spawns an internal threading model; each request is sent to
a worker thread within PHP, which has to synchronise with other threads in
order to access any aspect of global state.
I guess you are suggesting option (B), which is what I was referring to when
I said that global state would be arbitrarily shared - if handling a
particular request caused any global state to be changed, such as
registering an error handler, it could affect anything from 0 to 100% of
subsequent requests, depending on how the web server is configured.
The code therefore needs to avoid relying on any such global state at all,
which basically restricts you to a subset of the current language. For it to
become the default way of running PHP, huge changes would be needed to adapt
code to this new model.
The reason I mentioned threading is that under option (C), migration becomes
a bit easier in some ways: you can move some things which are currently
global state into an explicitly per-thread state, allowing old behaviour to
be emulated; and you can leave other things in synchronized global state,
like ini settings, solving the problem of 50% of my threads have a
different error handler registered.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yes, option (B) is more like.
Let me show in your PHP code, how the option that I like, we have the
actual application work that way in the pecl-event module, we are
satisfied, it is convenient and very fast for PHP.
This is a very rough and simplified code:
?php
class App
{
public static $db;// Persistent open connection to database
public static $redis; // Persistent open connection to Redis
public static $cache; // Persistent cache application
public $request;
public $response;
public $session;
public function __construct(HTTP $object)
{
$this-request = $object-request;
$this-response = $object-response;
}
public function open()
{
/*
Routing by $this-request, may be auth and open
$this-session (analog $_SESSION), or throw Exception.
*/
return $this;
}
public function run()
{
/*
Run your business logic...
*/
return $this;
}
public function close()
{
/*
Run finally logic, and cleaning output buffer
*/
$this-response-body = ob_get_clean();
return $this;
}
public static function init()
{
/*
Application configuration as static class state
*/
ob_start();
set_error_handler(/*...*/);
self::$db= new DBConnection;
self::$redis = new Redis;
self::$cache = new Cache;
}
}
// Bootstrap, run configuration
App::init();
// Handler WSGI (not multi-thread)
function application(HTTP $object)
{
$app = new App($object);
$app-open()-run()-close();
return
[
$app-response-code,
$app-response-headers,
$app-response-body
];
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 9 בפבר׳ 2015, at 02:04, Jordi Boggiano j.boggi...@seld.be wrote: On 08/02/2015 23:24, Zeev Suraski wrote: There's zero or virtually zero controversy surrounding the weak typing RFC, the one that was v0.1. The controversy wasn't (and isn't) about what was in v0.1, but rather, about what wasn't in there, namely, strict typing; Not in the contents of the v0.1 RFC itself, which, again, had zero controversy around and is effectively being voted on as an integral part of the current RFC. You have virtually all of the supporters of strict typing voting in favor of the current RFC, also voting in favor of the v0.1 elements which are an integral part of it. By this logic, the current proposal also does not take anything away from weak-typing proponents (which I guess I am a part of FWIW). It lets everyone be happy in their corner. I don't see how this is worse than one side winning by ignoring the other. It's simple. We have two proposals here, A and B. A - has pretty much everybody agreeing with is a good idea. Nobody objects to it. It's under consensus. B - has a large number of people thinking it's alien to PHP, and has many people objecting to it. The vote is on A+B. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new json, push generated file?
Hey: On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye pierre@gmail.com wrote: hi, Should we push json_parser.tab.c? Which is generated (re2c), just like what is done in date or other? I think we should, and also use a better name...(.tab.c?) thanks Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Design by Contract
Hi all, On Mon, Feb 9, 2015 at 3:41 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey rdlow...@gmail.com wrote: First, let me say that I have voted against the current scalar types RFC. Please do not let that color your evaluation of the rest of this message ... I want to go on record (for the n-th time) as being unhappy about any proposal that forces me to use php.ini. IMHO if it doesn't work with `$ php -n` then it's not a solution, it's a hack. Yes, I understand that opcodes php -n works (Well, we have data.timezone, though) with DbC. It should execute script in production mode. can't be removed (perf, yay!) without knowing ahead of time from php.ini. But the opcode removal difficulty should not be understood as a well we just have to do it this way, situation. Instead it ought to serve as a warning sign that this is not the right answer. Type checking is not a configuration-level issue; it is a language-level issue. Shoehorning it into the .ini file is just another band-aid on a broken arm. We tend to hold new proposals to the litmus test, can this be effectively accomplished in userland already? Well, yeah, in this case it really can. Making assertions optionally throw isn't some great advancement: // I can do this now if (!is_string($str) DEBUG) throw new Exception(you bad coder bro); In order to make robust and secure apps, functions/methods is better to have constraints. Type check is one of them. There are many people argue This language is secure and robust because it has _static_ types. // I'm all for brevity but does this really need an RFC? assert(is_string($str), you bad coder bro); That's a pretty insignificant, surface-level improvement. Mostly I just disagree with the assertion (see what I did there?) that this DbC RFC is remotely the same as what the scalar types RFC is trying to accomplish. And it certainly doesn't have universal support. DbC is not surface level change. It change application/code design a _lot_. In fact, DbC controversial what we have today and paradigm change. With modularized design, the more code is consolidated, the better code is. Therefore, parameter validity is checked deep into the code for example. Since these functions are rather simple basic functions that are used by many codes, the parameter validity is checked _many_ times over and over. This slows down execution. Solution? We should get rid of simple parameter validity checks from code written in basic functions. However, if we simply get rid of the check, we'll end up with too many bugs because caller forget about callee specifications(contracts). Here comes DbC, once we have contracts for pre/post conditions. We are safe from calling functions with invalid parameters during development, yet we have optimum performance for production since there is zero contract checks with production mode including opcode. My explanation is poor. So please research what is DbC more deeply. I think you'll like it once you understand the whole concept. Many languages have DbC support, in fact almost all languages, because DbC is extremely (It's extreme for me) useful to develop fast/secure apps. I forgot to mention the most important. DbC changes application/program design and the way of programming. It changes PHP applications being more robust/secure and faster. It changes PHP application development and testing, it will be more efficient with DbC. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: Annotated PHP 5-7 extension diff
Hey:
On Mon, Feb 9, 2015 at 5:06 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported. We have UPGRADING.INTERNALS which still needs some
love, but even if that covered everything it is sometimes hard to match
a bullet point in a long list of changes to actual code.
UPGRADING.INTERNALS is far from complete. Take for instance the
substantial changes in zend_hash_index_find(_ptr). Look at
PHP_FUNCTION(dba_list) in dba.c. In PHP 5.6 that is
if (zend_hash_index_find(EG(regular_list), i, (void **) le)==FAILURE)
{
continue;
}
PHP7:
if ((le = zend_hash_index_find_ptr(EG(regular_list), i)) == NULL) {
continue;
}
You'll have to use another macro, with a different number of arguments
and a different false test. There is nothing in UPGRADING.INTERNALS on
this. The info on this change can be found in the Wiki:
https://wiki.php.net/phpng-upgrading
But the wiki on its turn is not complete either. For instance it still
mentions
ZEND_FETCH_RESOURCE2(ib_link, ibase_db_link *, link_arg, link_id,
LE_LINK, le_link, le_plink);
Since the API cleanup interbase does not compile anymore. The reason is
that the API cleanup brought substantial changes in
ZEND_FETCH_RESOURCE2. I guess this command now must be something like
ib_link = (ibase_db_link *)zend_fetch_resource2(Z_RES_P(link_arg),
link_id, LE_LINK, le_link, le_plink);
But this is only an educated guess based on looking at changes in other
extensions. At the moment I am struggling with the PHP7 translation of
this block:
these are changes are made recently, I've updated the relates section
in that wiki.
thanks
#define GET_MOVIE_RESOURCE(ff_movie_ctx) {\
zval **_tmp_zval;\
if (zend_hash_find(Z_OBJPROP_P(getThis()), ffmpeg_movie,\
sizeof(ffmpeg_movie), (void **)_tmp_zval) == FAILURE) {\
zend_error(E_WARNING, Invalid ffmpeg_movie object);\
RETURN_FALSE;\
}\
\
ZEND_FETCH_RESOURCE2(ff_movie_ctx, ff_movie_context*, _tmp_zval, -1,\
ffmpeg_movie, le_ffmpeg_movie, le_ffmpeg_pmovie);\
}\
I have tried a lot of things, but nothing works so far...
An annotated diff would be very welcome! But more or less complete
documentation as well.
Jan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Annotated PHP 5-7 extension diff
Hi Maciej, On Mon, Feb 9, 2015 at 1:48 PM, Maciej Sobaczewski so...@php.net wrote: I'm totally aware that those files are tend to be more up-to-date thanks to placing them directly where core developers work. However, we have wiki pages for internals stuff, so why not move it to the manual and provide better Zend Hacker's Guide? There were some complaints about its incompleteness and creation of Zend Engine 3 is a great opportunity to fix it. Manual build system is awesome, but writing manual is pain indeed because it's sgml. For new release, updating the manual to current state would be difficult. We have missing items even in text files in source. I agree with you in general, but it's just not feasible it seems. I also have number of doc bugs that are not fixed yet... I had to spent few hours to know/get used to ZE3 API. However, thanks to folks who ported most of modules, I didn't had much problem. ZE3 API is more developer friendly than ZE2 as well. Basic stuff should be in source. IMO. Perhaps, we should use only the Wiki for additional internal stuff from now on. Keeping in sync wiki and manual seems to hard, but nobody will prevent make this effort if you would like to. ZE3 manual section is nice to have, but it may be better to use only wiki until we release PHP7. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
On 08/02/2015 20:33, Zeev Suraski wrote: FWIW, while I think strict types - stricter than even strict languages - don't belong in PHP, this syntax is clearly a step up from declare(), which was definitely not intended for this purpose. I'm kind of intrigued what purpose it *was* intended for. I've always found it a rather odd part of the language, but this seems as logical a use for it as any. For years, it had exactly one execution directive, which worked in concert with a runtime event handler (ticks=N + register_tick_function). In PHP 5.3, a completely unrelated directive was added, to specify the encoding of the file (something that more obviously has to be detected by the compiler). Was there an original idea of what it would be used for that never came to fruition? Or is there something I'm missing that connects ticks and encoding, but excludes strict_types? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
hi,
On Mon, Feb 9, 2015 at 2:44 AM, Andrea Faulds a...@ajf.me wrote:
Hi,
I’m posting this in a new thread since people might (reasonably) be ignoring
further responses to the [VOTE] thread.
I’m considering a small change to the Scalar Type Hints RFC, specifically
about syntax. Quite a few people have said they don’t like the declare()
syntax, and it’s easy to see why. It’s rather verbose, it has all the quirks
of declare() (such as block syntax, not respecting scope), and it’s rather
ugly.
Instead, I’m wondering if the following might be better:
?php strict
Which would be used like so:
?php strict
function foobar(): int {
return 1.0; // error!
}
It’d be a per-file directive, so there’d be zero mixing of modes within one
file, and you’d avoid the quirks of declare().
It’s also a lot shorter, and it resembles Hack’s syntax:
?hh // strict
Of course, changing this would mean restarting the vote, but it’s only been
three days, we’re less than a quarter of the way through voting.
Thoughts? Thanks!
(By the way, I’d appreciate it if this thread didn’t turn into yet another
discussion of how and whether scalar type hints are a bad/good idea. We
already have at least four threads on that subject. I’m just considering a
specific change of syntax.)
I am not sure I like this. It is somehow not very phpish :)
May I ask why you like to do it? Declare works well and only need a
couple of line to make it work like encoding. We may fix as well other
related issues, nothing that does not look fixable.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 08/02/2015 23:24, Zeev Suraski wrote: There's zero or virtually zero controversy surrounding the weak typing RFC, the one that was v0.1. The controversy wasn't (and isn't) about what was in v0.1, but rather, about what wasn't in there, namely, strict typing; Not in the contents of the v0.1 RFC itself, which, again, had zero controversy around and is effectively being voted on as an integral part of the current RFC. You have virtually all of the supporters of strict typing voting in favor of the current RFC, also voting in favor of the v0.1 elements which are an integral part of it. By this logic, the current proposal also does not take anything away from weak-typing proponents (which I guess I am a part of FWIW). It lets everyone be happy in their corner. I don't see how this is worse than one side winning by ignoring the other. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dragging the legacy users forward.
On 09/02/15 00:05, Rowan Collins wrote: Some of the new 'styles' of writing things are going to make things considerably worse for those who are going to have to maintain this code in the future. If you're writing code that you know will be hard to maintain in the future, you're doing something wrong. If by slavishly following a style guide you've ended up with a poor architecture, you need a better style guide, or a better understanding of why those styles are preferred. Alternatively, I may have misunderstood that sentence, in which case I apologise in advance. Something *I* have been asking for for the last few years IS a better 'style guide' ... There are a growing number of 'styles' and the current debate is to allow even more! Just about every framework has a different style of handling database abstraction, and that seems to change every major version as well. All of my own code is based around ADOdb, but now it seems THAT is not an acceptable style of code these days. Anyway I now have PHP56.lsces.org.uk running with the latest PHP5. It's throwing megabytes of data into the error log but there ACTUALLY seem to be less in the php7 error log ... need to figure that out, but I've currently hit the latest brick wall as mbstring is not compiling! Most of the others have compiled fine, but currently there is a blank front page until I can work out what is going wrong ... that and smarty is throwing errors ... -- 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] new json, push generated file?
Hi! Should we push json_parser.tab.c? Which is generated (re2c), just like what is done in date or other? I think we should, otherwise building from release package without re2c would be impossible, and I think before it was possible. In any case, we should be consistent - if we commit generated files (which we do), we should do it everywhere. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski z...@zend.com wrote: I'm well aware of it as I wrote that policy. The goal of the policy was to prevent a situation where a temporary majority can introduce features into the language that would later on be impossible to reverse. It's not by any stretch a good mechanism to solve controversial votes, which again, should ideally be avoided as much as possible. It's just that there isn't a better mechanism. I know I'm unfairly paraphrasing you, but it sounds like you are saying that for things that you don't have strong feelings about, then you're fine if the others vote amongst themselves. But for things that matter to you, you want to reserve the right to prevent change. Is there a way to fairly describe what you consider too controversial to vote on? The problem I see with votes for this type of feature is that you probably have a breakdown of something like: - 10% of people don't want scalar type hints - 20% of people want both, but 50% of them would vote for either weak or strong - 35% of people want strict, but 80% of them are fine with weak - 35% of people want weak, but 80% of them are fine with strong So if a strict-only vote happens first, you get 73% to say yes. If weak-only vote happens first, you get 73% to say yes. (I'm obviously just making up these numbers with no scientific basis, but I think the principle is valid.) The only way to be fair IMO is to hold a vote where you rank those four options (weak, strong, both, neither) and hold an instant run-off vote where the first majority wins. And if 'neither' wins, then agree that the topic cannot be revisited until next major version, so that everybody can rest for 5 years. ;) -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: new json, push generated file?
Pierre Joye in php.internals (Mon, 9 Feb 2015 09:40:21 +0700): Should we push json_parser.tab.c? Which is generated (re2c), just like what is done in date or other? Yes, you should. I ran into this problem when I tried to compile PHP7 from git head. The Windows builds are currently broken: http://windows.php.net/downloads/snaps/master/r0698901/logs/make-nts-windows-vc11-x86-r0698901.html Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new json, push generated file?
On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui larue...@php.net wrote: Hey: On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye pierre@gmail.com wrote: hi, Should we push json_parser.tab.c? Which is generated (re2c), just like what is done in date or other? I think we should, and also use a better name...(.tab.c?) that too :) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Design by Contract
Hi Daniel, On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey rdlow...@gmail.com wrote: First, let me say that I have voted against the current scalar types RFC. Please do not let that color your evaluation of the rest of this message ... I want to go on record (for the n-th time) as being unhappy about any proposal that forces me to use php.ini. IMHO if it doesn't work with `$ php -n` then it's not a solution, it's a hack. Yes, I understand that opcodes php -n works (Well, we have data.timezone, though) with DbC. It should execute script in production mode. can't be removed (perf, yay!) without knowing ahead of time from php.ini. But the opcode removal difficulty should not be understood as a well we just have to do it this way, situation. Instead it ought to serve as a warning sign that this is not the right answer. Type checking is not a configuration-level issue; it is a language-level issue. Shoehorning it into the .ini file is just another band-aid on a broken arm. We tend to hold new proposals to the litmus test, can this be effectively accomplished in userland already? Well, yeah, in this case it really can. Making assertions optionally throw isn't some great advancement: // I can do this now if (!is_string($str) DEBUG) throw new Exception(you bad coder bro); In order to make robust and secure apps, functions/methods is better to have constraints. Type check is one of them. There are many people argue This language is secure and robust because it has _static_ types. // I'm all for brevity but does this really need an RFC? assert(is_string($str), you bad coder bro); That's a pretty insignificant, surface-level improvement. Mostly I just disagree with the assertion (see what I did there?) that this DbC RFC is remotely the same as what the scalar types RFC is trying to accomplish. And it certainly doesn't have universal support. DbC is not surface level change. It change application/code design a _lot_. In fact, DbC controversial what we have today and paradigm change. With modularized design, the more code is consolidated, the better code is. Therefore, parameter validity is checked deep into the code for example. Since these functions are rather simple basic functions that are used by many codes, the parameter validity is checked _many_ times over and over. This slows down execution. Solution? We should get rid of simple parameter validity checks from code written in basic functions. However, if we simply get rid of the check, we'll end up with too many bugs because caller forget about callee specifications(contracts). Here comes DbC, once we have contracts for pre/post conditions. We are safe from calling functions with invalid parameters during development, yet we have optimum performance for production since there is zero contract checks with production mode including opcode. My explanation is poor. So please research what is DbC more deeply. I think you'll like it once you understand the whole concept. Many languages have DbC support, in fact almost all languages, because DbC is extremely (It's extreme for me) useful to develop fast/secure apps. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
Hi Guilherme,
On Mon, Feb 9, 2015 at 1:44 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Class invariants could be done as this example:
class Foo {
private function isValidState() {
// Checks class's state and returns boolean
}
public function doSomething($args) {
// Some complex operation over Foo instance using $args
// then...
assert $this-isValidState(): $this; // it would call
Foo::__toString() for AssertionError message
}
}
Another example of pre and post conditions:
function foo($number) {
// pre-condition
assert is_numeric($number): '...';
// Some expensive operation creating $value as response
// post-condition
assert someCheckWith($value): '...';
return $value;
}
A good explanation about use-cases can be found here
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#class-invariants
Thank you for the info.
I had this syntax in mind.
class Foo {
__invariant() {
// Ignored for production.
// Check class state, every method calls invoke this method
before/after except
// __construct()/__wakeup()/__set_state() - after only
// __destruct() - before only
}
}
// Framework developer shouldn't use this. Leave this function for app
developers.
function __invariant() {
// Ignored for production.
// Invariant conditions of functions invoked for every function calls
// to check app state. e.g. global vars,etc
}
__invariant() has similar issue as __autoload(), we may be better to
provide generic registration
method.
Just my initial thought for discussion.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] new json, push generated file?
Hey: On Mon, Feb 9, 2015 at 1:44 PM, Pierre Joye pierre@gmail.com wrote: On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui larue...@php.net wrote: Hey: On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye pierre@gmail.com wrote: hi, Should we push json_parser.tab.c? Which is generated (re2c), just like what is done in date or other? I think we should, and also use a better name...(.tab.c?) that too :) simply, json_parser.c is good something like: https://gist.github.com/laruence/f33903266cec737088aa thanks -- Pierre @pierrejoye | http://www.libgd.org -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Zeev, On 8 Feb 2015, at 23:24, Zeev Suraski z...@zend.com wrote: It's not stretching the truth or even slightly bending it, considering the RFC currently being voted on is a superset of that RFC. That has no relevancy. There's zero or virtually zero controversy surrounding the weak typing RFC, the one that was v0.1. The controversy wasn't (and isn't) about what was in v0.1, but rather, about what wasn't in there, namely, strict typing; So, then, there was controversy around that RFC. The way it should have went is voting on the weak typing RFC, around which there was (and probably still is) almost consensus. Again, there was not consensus. The RFC was controversial, especially outside of internals, but even on internals around half the people who responded *were not positive*. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP
2015-02-09 1:48 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
On 08/02/2015 22:48, S.A.N wrote:
Hi internals.
I really hope that in the future PHP 7, there will be new server API.
May be you interested to know about them, here is the link, I am not
the author of development:
https://github.com/unbit/uwsgi-phpsgi/
But the problem is that in PHP there are no standards for such interfaces.
Now it is implemented like this:
?php
function application($env)
{
return ['200 OK', ['Content-Type' = 'text/plain'], 'Hello, world!'];
}
?
I think this is a good opportunity to review the old interface ($_GET,
$_POST, ...) and start using the API internal HTTP module.
This all breaks backward compatibility, not $_GET, $_POST, ...
But this WSGI SAPI will used only new PHP code (not PHP legacy base).
This is a good opportunity to create something new and not be backward
compatible.
What do you think about this?
The problem with creating an event-based API for PHP is that you don't just
have to rethink superglobals, you have to rethink absolutely everything that
currently acts as global state:
- global variables
- static variables within functions
- class static variables
- dynamic settings (ini_set etc)
- globally registered callbacks (set_error_handler, spl_autoload_register,
etc)
- the counters of include_once() and require_once()
- any function which implicitly fetches data based on some previous action
(e.g. libxml_get_errors)
If the language is not itself multi-threaded, all of these become
arbitrarily shared once per thread the server spins up and reuses. If it
*is* multi-threaded, you have another set of headaches about how both the
engine and the userland can share and synchronize.
Not that I don't like the idea, but it's a huge project, with potential for
profoundly affecting the language.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
You're right, but there is no threading issues.
One worker synchronously execute requests, but may run parallel many workers.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] new json, push generated file?
hi, Should we push json_parser.tab.c? Which is generated (re2c), just like what is done in date or other? Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] scalar type hints
On Feb 9, 2015 10:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Matt and all, On Mon, Feb 9, 2015 at 6:52 AM, Matt Parker m...@lamplightdb.co.uk wrote: The first question was 'Did you read the RFC' and the second 'Would you like the RFC to pass'. I set it up Friday morning (GMT) and tweeted it around a bit (I have a grand total of 58 followers on twitter). So this relates to version 0.3 As of now, 306 people have responded, a lot more than I anticipated. 84% said they read the RFC; 83% would like it to pass (full responses here: https://www.surveymonkey.com/results/SM-Q8KRRZV7/, the survey itself here: https://www.surveymonkey.com/s/SDB2V6Z). They don't know about DbC discussion probably. I thought we were no where near to implement DbC, so I was willing to vote +1 initially. However, DbC is coming close! DbC brings much more flexibility, strict/loose constraints, performance, security, better documentation and more. DbC suitable for weakly typed PHP perfectly. Therefore, I'm holding my vote now. I hope everyone have an attention to DbC and consider thoughtfully. Imho they are totally different things. One is a core root feature (scalar hinting). Then we have annotations, which can be used(and is very often used for contracts) by DbC. However starting to stop one in favor of another is a strategic mistake. I left alone the DbC or annotations as phpdoc as we have discussed that to death already :) Cheers, Pierre
RE: [PHP-DEV] [VOTE] Scalar Type Hints
So, controversy is where a lot of people disagree - and there were numerous people in the original thread who disagreed with the RFC and preferred strict types. I actually tallied them in a reply to Zeev (which I later quoted in a reply to Andi). There were almost as many people against the proposal as in favour. This is to say nothing as to how it was received outside internals which, from my experience on reddit, Twitter and StackOverflow, was even less positive than internals, considerably so. So, I think that to say that there was “zero controversy” is certainly stretching the truth. Really, I’m yet to see any scalar type hinting discussions which haven’t had some controversy. It's not stretching the truth or even slightly bending it, considering the RFC currently being voted on is a superset of that RFC. There's zero or virtually zero controversy surrounding the weak typing RFC, the one that was v0.1. The controversy wasn't (and isn't) about what was in v0.1, but rather, about what wasn't in there, namely, strict typing; Not in the contents of the v0.1 RFC itself, which, again, had zero controversy around and is effectively being voted on as an integral part of the current RFC. You have virtually all of the supporters of strict typing voting in favor of the current RFC, also voting in favor of the v0.1 elements which are an integral part of it. The way it should have went is voting on the weak typing RFC, around which there was (and probably still is) almost consensus. Right afterwards, vote on the strict elements that you added in v0.2. That would have been the one way to know what the voter base truly thinks. Right now, I believe many people are voting in favor thinking that otherwise we'd get nothing, and again - pretty much nobody is supportive of 'nothing'. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 9 בפבר׳ 2015, at 01:45, Andrea Faulds a...@ajf.me wrote: Hi Zeev, On 8 Feb 2015, at 23:24, Zeev Suraski z...@zend.com wrote: It's not stretching the truth or even slightly bending it, considering the RFC currently being voted on is a superset of that RFC. That has no relevancy. I'll have to disagree here. It has all the relevancy in the world. I'll save the list and us all the obvious explanation, though. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Mon, Feb 9, 2015 at 6:24 AM, Zeev Suraski z...@zend.com wrote: So, controversy is where a lot of people disagree - and there were numerous people in the original thread who disagreed with the RFC and preferred strict types. I actually tallied them in a reply to Zeev (which I later quoted in a reply to Andi). There were almost as many people against the proposal as in favour. This is to say nothing as to how it was received outside internals which, from my experience on reddit, Twitter and StackOverflow, was even less positive than internals, considerably so. So, I think that to say that there was “zero controversy” is certainly stretching the truth. Really, I’m yet to see any scalar type hinting discussions which haven’t had some controversy. It's not stretching the truth or even slightly bending it, considering the RFC currently being voted on is a superset of that RFC. There's zero or virtually zero controversy surrounding the weak typing RFC, the one that was v0.1. The controversy wasn't (and isn't) about what was in v0.1, but rather, about what wasn't in there, namely, strict typing; Not in the contents of the v0.1 RFC itself, which, again, had zero controversy around and is effectively being voted on as an integral part of the current RFC. You have virtually all of the supporters of strict typing voting in favor of the current RFC, also voting in favor of the v0.1 elements which are an integral part of it. The way it should have went is voting on the weak typing RFC, around which there was (and probably still is) almost consensus. Right afterwards, vote on the strict elements that you added in v0.2. That would have been the one way to know what the voter base truly thinks. Right now, I believe many people are voting in favor thinking that otherwise we'd get nothing, and again - pretty much nobody is supportive of 'nothing'. Zeev, we know it by now. You do not like it. And given past experiences nothing, virtually nothng, tells me that you will accept anything anyway. There is a vote, you do not like the RFC or part of it, vote no. But this constant attempt to get exactly what you want and do almost everything possible to get it is getting very counter productive. Not the first time but hopefully the last. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Mon, Feb 9, 2015 at 7:47 AM, Andrey Andreev n...@devilix.net wrote: Hi, On Mon, Feb 9, 2015 at 2:10 AM, Pierre Joye pierre@gmail.com wrote: There is a vote, you do not like the RFC or part of it, vote no. But this constant attempt to get exactly what you want and do almost everything possible to get it is getting very counter productive. I want to note that this should count for both sides. Any time that somebody states that they don't like the RFC, there are at least two people trying to convince that person that it is good and they should support it. This is ... annoying, to say the least. Please just let the voters decide on their own. Full Ack. On the other hand tech discussions (like declare restrictions and how it could be improved) or the likes are fine. It will be good for php no matter the outcome. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] scalar type hints
Hi Matt and all, On Mon, Feb 9, 2015 at 6:52 AM, Matt Parker m...@lamplightdb.co.uk wrote: The first question was 'Did you read the RFC' and the second 'Would you like the RFC to pass'. I set it up Friday morning (GMT) and tweeted it around a bit (I have a grand total of 58 followers on twitter). So this relates to version 0.3 As of now, 306 people have responded, a lot more than I anticipated. 84% said they read the RFC; 83% would like it to pass (full responses here: https://www.surveymonkey.com/results/SM-Q8KRRZV7/, the survey itself here: https://www.surveymonkey.com/s/SDB2V6Z). They don't know about DbC discussion probably. I thought we were no where near to implement DbC, so I was willing to vote +1 initially. However, DbC is coming close! DbC brings much more flexibility, strict/loose constraints, performance, security, better documentation and more. DbC suitable for weakly typed PHP perfectly. Therefore, I'm holding my vote now. I hope everyone have an attention to DbC and consider thoughtfully. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: new json, push generated file?
On Mon, Feb 9, 2015 at 2:48 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Pierre Joye in php.internals (Mon, 9 Feb 2015 09:40:21 +0700): Should we push json_parser.tab.c? Which is generated (re2c), just like what is done in date or other? Yes, you should. I ran into this problem when I tried to compile PHP7 from git head. The Windows builds are currently broken: http://windows.php.net/downloads/snaps/master/r0698901/logs/make-nts-windows-vc11-x86-r0698901.html Yes, that's where I notice it was not present when I was working on fixing the build in the 1st place (adding re2c call on win) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
On 09/02/2015 00:05, Andrea Faulds wrote: Secondly, it is less specific than the current proposal - it suggests that PHP has a generic strict mode, rather than a strict type-checking mode. It could be renamed to strict_types, but that loses some elegant. Would more strict features be added to this mode later? No. Or would other keywords be added so that you could, ahem, declare several directives at the top of your block? No. I think this is all rather optimistic - if you use a specific term like strict_types, people will want to use this syntax for other keywords; if you use something as general as strict, they will want to add additional semantics to the existing keyword. Thirdly, it has all the same scoping issues as declare() - you can break a function up into multiple ?php ... ? blocks, so it's still possible to switch it halfway through a declaration, I’ve already sent an email in this thread about possible approaches to handling multiple blocks. My preferred solution would not allow what you describe, and instead behave like namespaces (must be in first block, affects entire file). If this magic token has the extra effect of causing ? to be ignored, that's a fairly major and unrelated feature, which would probably need its own RFC. ? isn’t ignored - PHP blocks aren’t, and never have, been considered the same as separate files. This was in response to your suggestion in the other message that that was a possible (though not your preferred) way to deal with the scoping issue. I edited my post for brevity, and didn't make the reference clear. It's not like non-block namespace declarations having to be at the top of the file, because that is still a separate statement, it just has to be the *first* statement; whereas this appears to be designed to merge with the non-statement opening tag. Is there really an important difference between first statement, and first opening tag? The main difference in behaviour is empty blocks. I guess it's more that statements, wherever they appear, are a recognisable part of the language. Tokens sharing a line with the opening tag aren't, and I don't see why this feature is so special that it requires the creation of a whole new syntax feature. If you're going to go that far, why not just disallow the block-level syntax of declare() for this case, if that is the complaint? Or if the problem is the non-block syntax, why not enforce that a non-block declare(strict_types) be at the top of the file? Well, it’s not just that which is the problem: declare() is rather verbose and ugly. Also, having it behave differently from all other declare() statements would bring into question why we even bother reusing the declare() syntax. I'd rather verbose and clear than concise and vague. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi Yasuo,
Design by Contract could be used at the top of Annotation if (and only if)
it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's time to propose something at the top
of another thing that is still far from being reality.
It would follow somehow a similar approach of what Symfony validators do:
http://symfony.com/doc/current/book/validation.html but it would be called
at possible 3 times: pre-execution, in-execution (using around and bound to
an external class) and post-execution.
However, I keep myself asking if this is a good idea. It obviously brings a
certain level of AOP to PHP, but I'd rather take a simplistic approach such
as the one suggested by Stas but with a few adjustments.
His approach is more inline to C and C++, but I like a more customizable
Java style assertion support
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
Example:
function foo($name) {
assert $name !== '': Name must not be an empty value;
}
This would be similar to this:
function foo($name) {
if ($name === null) {
throw new AssertionError(Name must not be an empty value);
}
}
Basically, new grammar to be supported would be something like this:
assert_statement:
T_ASSERT expr ':' expr ';'
;
Where the first expr is a boolean expression and the second expr must
return a value (cannot be null).
This would be a good start for PHP, even though Java does not recommend to
use this for argument's method check (
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage),
but I consider that since PHP is not a strict language, we do not have the
same privileges by automating this check form arguments itself.
That is my personal suggestion for DbC, which does not fully align with
what it was proposed, but since you asked... here it is.
[]s,
On Sun, Feb 8, 2015 at 8:22 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Stas,
On Mon, Feb 9, 2015 at 8:11 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Following our conversation, I tried to imagine how DbC should look like
in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
requre(input-assert-expression)
ensure(output-assert-expression)
{
...
}
Why not do it simpler?
function foo() {
// require
assert(input-assert-expression);
...
// ensure
assert(output-assert-expression);
}
I'm oversimplifying a bit, but in general, why we need more places to
have code in the function than the actual code of the function? It would
be harder to parse, to read, to maintain, to debug, to profile, etc. and
I'm not sure what exactly it provides that can't be done by plain
regular code inside the function.
If we're concerned about the costs of assert, we could make special
provision in the compiler for zero-cost asserts. It doesn't require
moving code out of the function.
Interesting idea. I like it.
The only draw back I can see now is that this may make post/pre condition
retrieving
harder for automatic documentation. We may think of solution for this.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Re: [PHP-DEV] Design by Contract
Hi Guilherme,
On Mon, Feb 9, 2015 at 11:58 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Design by Contract could be used at the top of Annotation if (and only if)
it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's time to propose something at the top
of another thing that is still far from being reality.
It would follow somehow a similar approach of what Symfony validators do:
http://symfony.com/doc/current/book/validation.html but it would be
called at possible 3 times: pre-execution, in-execution (using around and
bound to an external class) and post-execution.
However, I keep myself asking if this is a good idea. It obviously brings
a certain level of AOP to PHP, but I'd rather take a simplistic approach
such as the one suggested by Stas but with a few adjustments.
His approach is more inline to C and C++, but I like a more customizable
Java style assertion support
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
Example:
function foo($name) {
assert $name !== '': Name must not be an empty value;
}
This would be similar to this:
function foo($name) {
if ($name === null) {
throw new AssertionError(Name must not be an empty value);
}
}
Basically, new grammar to be supported would be something like this:
assert_statement:
T_ASSERT expr ':' expr ';'
;
Where the first expr is a boolean expression and the second expr must
return a value (cannot be null).
This would be a good start for PHP, even though Java does not recommend to
use this for argument's method check (
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage),
but I consider that since PHP is not a strict language, we do not have the
same privileges by automating this check form arguments itself.
That is my personal suggestion for DbC, which does not fully align with
what it was proposed, but since you asked... here it is.
Thank you.
Since assert is going to have zero performance penalty, Stas proposal would
work.
We have to think of how invariants should be.
Joe, could you add Proposal section to the RFC.
https://wiki.php.net/rfc/expectations
Currently, it does not have Proposal section and it's harder to
understand what the
RFC is. Then, could you start vote? New assert is valuable regardless of
DbC.
The RFC will encourage users to use assert(), my little concern with Stas's
proposal
is misuse/abuse of assert(). Stas's proposal is simplest, but I'm not sure
if we should go
for it or not.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
Hi Yasuo,
Class invariants could be done as this example:
class Foo {
private function isValidState() {
// Checks class's state and returns boolean
}
public function doSomething($args) {
// Some complex operation over Foo instance using $args
// then...
assert $this-isValidState(): $this; // it would call
Foo::__toString() for AssertionError message
}
}
Another example of pre and post conditions:
function foo($number) {
// pre-condition
assert is_numeric($number): '...';
// Some expensive operation creating $value as response
// post-condition
assert someCheckWith($value): '...';
return $value;
}
A good explanation about use-cases can be found here
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#class-invariants
[]s,
On Sun, Feb 8, 2015 at 11:24 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Guilherme,
On Mon, Feb 9, 2015 at 11:58 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Design by Contract could be used at the top of Annotation if (and only
if) it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's time to propose something at the top
of another thing that is still far from being reality.
It would follow somehow a similar approach of what Symfony validators do:
http://symfony.com/doc/current/book/validation.html but it would be
called at possible 3 times: pre-execution, in-execution (using around and
bound to an external class) and post-execution.
However, I keep myself asking if this is a good idea. It obviously brings
a certain level of AOP to PHP, but I'd rather take a simplistic approach
such as the one suggested by Stas but with a few adjustments.
His approach is more inline to C and C++, but I like a more customizable
Java style assertion support
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html
Example:
function foo($name) {
assert $name !== '': Name must not be an empty value;
}
This would be similar to this:
function foo($name) {
if ($name === null) {
throw new AssertionError(Name must not be an empty value);
}
}
Basically, new grammar to be supported would be something like this:
assert_statement:
T_ASSERT expr ':' expr ';'
;
Where the first expr is a boolean expression and the second expr must
return a value (cannot be null).
This would be a good start for PHP, even though Java does not recommend
to use this for argument's method check (
http://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage),
but I consider that since PHP is not a strict language, we do not have the
same privileges by automating this check form arguments itself.
That is my personal suggestion for DbC, which does not fully align with
what it was proposed, but since you asked... here it is.
Thank you.
Since assert is going to have zero performance penalty, Stas proposal
would work.
We have to think of how invariants should be.
Joe, could you add Proposal section to the RFC.
https://wiki.php.net/rfc/expectations
Currently, it does not have Proposal section and it's harder to
understand what the
RFC is. Then, could you start vote? New assert is valuable regardless of
DbC.
The RFC will encourage users to use assert(), my little concern with
Stas's proposal
is misuse/abuse of assert(). Stas's proposal is simplest, but I'm not sure
if we should go
for it or not.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
