[PHP-DEV] (off topic) Array to string conversion (Was: Re: [PHP-DEV] Scalar Type Hints v0.4)
Le Thu Feb 19 2015 at 00:38:25, François Laupretre franc...@php.net a écrit : This is definitely not the same case as generating a notice on array to string (and why did you generate a notice instead of E_DEPRECATE, we would be rid of this crap now). I haven't decided that without discussing [1] it. E_DEPRECATED is meant for something that may/will not work in the future and the plan was not to stop converting arrays as the string Array when it happens. Moreover, no other bad conversion used E_DEPRECATED and it would have been inconsistent IMO. Note that there is room for improvements considering that weird conversions are using one of E_NOTICE, E_WARNING, E_ERROR or E_RECOVERABLE_ERROR depending on the case. Feel free to propose something in this regard, I'm all for consistencies, provided that it gives a sufficient amount of BC. Regards, Patrick [1] http://marc.info/?l=php-internalsm=130709981705863
Re: [PHP-DEV] [RFC] Exceptions in the engine
Rowan Collins wrote in message news:54e4fac2.7060...@gmail.com...
Tony Marston wrote on 18/02/2015 10:52:
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it could be a permissions error, for example). Is there any plan to
convert procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
So, no, since that's currently an E_WARNING, there is no current plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.
That has absolutely nothing to do with OO vs procedural code, though.
A procedural function could well have an error condition which should
be fatal if unhandled, but can usefully be caught somewhere up the
stack, which is basically what an exception is for. Any procedural
function which currently issues an E_ERROR or E_RECOVERABLE_ERROR is a
candidate to be converted under the current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists
with some other functions as well, so it would be nice to be able to
put the function in a try . catch block so that any and every
message could be made available. It is quite obvious that changing
fopen() to use exceptions would be a major BC break for all exiting
applications, so my question is this:
Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not
then don't throw an exception. I realise that this might be tricky to
implement, but if it could be it would allow the developer to choose
whether he/she wanted to use exceptions or not instead of having the
choice forced upon him/her.
Is this possible? Or am I just dreaming?
The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call in a try ... catch block
for the purposes of that check, or not? If putting try { ... } around an
entire application caused all calls to fopen(), in every library it
used, to stop returning false, you'd have exactly the same BC issue as
just changing it permanently.
function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}
function load_data() {
$fh = fopen(...);
...
}
So no, I'm afraid it's probably not possible.
Regards,
Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within *that* function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.
If the exception is only thrown when the try - catch is in the same scope,
is there really much advantage to it being an exception? When you're that
close to the code, sticking an if ( $fh === false ) { ... } around it
really isn't that much different from catch(IOException $e) {
The advantage is that you can obtain the reason for the error. All that
happens with fopen() at the moment is that it returns FALSE which tells you
that it has failed, but it does not tell you why. This is a classic example
of the semipredicate problem for which exceptions were originally designed.
Having the problem be detectable in a higher scope is kind of the point of
exceptions.
So is the ability of catching an exception immediately it is thrown so that
you can obtain the error message. Having the ability to deal with an
exception at a higher level is only relevant if you don't deal with it
immediately, either by design or by accident.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Expectations
Morning internals, The expectations RFC is now in voting phase: https://wiki.php.net/rfc/expectations#vote Cheers Joe
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Thursday, February 19, 2015 9:00 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] Reviving scalar type hints On 02/17/2015 01:30 PM, Zeev Suraski wrote: Yes, I already know that. At this point, if I could rephrase the camps a bit I see two different sets of priorities: 1) PHP should do what seems obviously safe to do, to make life easiest for developers. That is, it's patently obvious that 32 and 32 are equivalent, so don't make developers worry about the distinction because to them there isn't one. This is an entirely reasonable position. 2) PHP would benefit hugely from static analysis tools and compile-time type-based optimizations, but those are only possible with code that is strongly typed. Currently such tools do not really exist, but with compile- time-knowlable information could be written and even incorporated into future versions of PHP without API breaks. (I think Anthony demonstrated earlier examples of function calls no longer being slow, for instance, if the type juggling could be removed at compile time.) This is an entirely reasonable position. Larry, There's actually very little difference between coercive type hinting and strict type hinting in terms of performance. If you read what both Dmitry and Anthony said, it should be clear that the vast majority of gains can be had even without any sort of type hinting at all - and as Stas pointed out, JavaScript has some mind blowing JIT optimizations without any explicit type info at all. Moreover, I think it's easy to lose the forest from the trees here, by focusing on a very narrow piece of code - without looking at the bigger picture. Ultimately, if you have a piece of data that you want to pass from a caller to a callee, it could be under one of three labels: 1. A piece of data the callee can use as-is. 2. A piece of data the callee can use after conversion (be it explicit or implicit). 3. A piece of data the callee cannot/shouldn't use. When comparing strict and coercive type hints, there's no difference between them in terms of #1; There's a subtle difference with #3 - but only in the error situation. In other words, for coercive type hints, it would just take a bit more time before they fail, because they have to conduct a few more checks. However, that's an error situation anyway, which is either already going to bail out, or go through error handling code - which would be very slow anyway. So focusing on #2, in a practical real world situation - the difference is actually a lot more subtle than people might think if they only zoom into on the area around parameter passing. The bigger picture is, what would the code author - the one making the call - want to do, semantically? In other words, if you have 32 coming from a database or whatnot, are you likely to want an API that accepts an int to be able to use that? I think the answer is almost always yes. So practically, what will happen with strict typing is that you'd explicitly cast it to int, while with coercive typing - you'd rely on the language to do it for you. Arguably, very little difference between the two in terms of performance. Note that it's possible people will be able to come up with various edge cases where strict typing might somehow alert you to a situation that may push you to change your code in a way it might end up being slightly faster. But those will be edge cases and should be taken in the context - in the vast majority of code patterns, there's zero difference between the two approaches in terms of performance. In terms of functionality, however, there's actually a substantial difference between the two - explicit casting is a lot more aggressive than the coercion rules we're thinking about for coercive type hints. It'll happily and silently coerce Apple into 0, 100 dogs into 100, and 3.1415 into 3. Now, diving back to future potential AOT/JIT, it's simply not true that there's any gain at all from strict typing - or at least, neither Dmitry (who wrote a full JIT compiler for PHP that runs Mandelbrot as fast as gcc does) nor me were able to understand them. Anthony spoke about being able to completely eliminate the zval container and all associated checks, so that in certain situations you'd be able to map a PHP integer all the way down to a C (or asm) integer. That can certainly be done, but it has nothing to do with strict vs. coercive type hints. Here's why: 1. At this point I think it's clear to everyone that inside the called function, there's zero difference between strict and coercive typing (or even the weak typing we were talking about earlier). They're 100% guaranteed to receive what they asked, either because values were coerced or blocked from even making it into the function. 2. On the outside calling code - if you can conduct the level of type inference that would enable you to safely compile a
Re: [PHP-DEV] [RFC] Exceptions in the engine
Nikita Nefedov wrote in message news:CALuY8tjUq70eLkV-MbDi-fEXZvWTFi82zCNmWr7tmvpiES9=p...@mail.gmail.com... On 18 Feb 2015 13:53, Tony Marston tonymars...@hotmail.com wrote: Could it be restricted to the current scope? In your example the call to fopen() exists in the load_data() function and is not in a try ... catch block within *that* function, so the fact that the call to load_data() is within a try ... catch block should be irrelevant as it is in a different scope. Hi Tony, This sounds very hacky. You could say that every piece of code is a hack with the only difference being that some hacks are ugly while others are beautiful. If you want exceptions with file/stream functions I suggest you to find some open library out there that can handle your user case or you can use SplFileObject. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On 19 בפבר׳ 2015, at 22:08, Anthony Ferrara ircmax...@gmail.com wrote: Zeev, Based on Sara's clarification in this thread, I owe you a formal apology. I interpreted something she said incorrectly, which was then compounded by messages in private and on-list this morning. I then attributed both of you qualities and motives that have been proven false. For this, I am sorry for any implication or direct acquisition that I made against you. Apology accepted! No worries. I do believe that the best way forward is parallel proposals, as I believe that we have different goals. So I look forward to seeing yours, and will continue forward with mine. Hopefully this differing of opinion can be rectified before too long. Me too! Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
There isn't legitimate technical justification for or against using custom exceptions. Since it's entirely based on preference, and the kind of utilitarian argument you can make for their use, it's acceptable that this is resolved as part of the vote. It's not a huge deal. Cheers Joe On Thu, Feb 19, 2015 at 5:34 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Feb 19, 2015 at 9:13 AM, Leigh lei...@gmail.com wrote: On 19 February 2015 at 15:45, Pierre Joye pierre@gmail.com wrote: Still, no announce for a discussion about this specific RFC. And really, the content of the RFC is almost empty, pointing to the ML archive is really not the right way :) There was an RFC announce thread 3 days ago. I agree 3 days is a short period of time, but the announce thread existed. Maybe it was a reply to DbC with a changed subject and your mail client didn't show it as new? I don't know, there was definitely a thread though. I mentioned that thread in my comment. It is still way behind what should be done when creating a new RFC, let alone pushing it to the vote phase. On 19 February 2015 at 16:06, Pierre Joye pierre@gmail.com wrote: I like the concept and idea but still not sure about the custom exception vs AssertException. Looking at the implementation, it seems that the custom exception still has to descend from AssertException https://github.com/php/php-src/pull/1088/files#diff-232f2dffbb06c0b6004724d8a498e7e7R248 That seems like a good restriction to me. You can still catch everything with AssertException but you can make it more specific if you want. I did not comment on what should be done, while I do consider this open question as a blocker to actually take a good decision for this RFC. I do think it should be discussed, answered and voted either at the same time or before this RFC. -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
Nikita (and all), * Subclassing: Should there be more specific subclasses of EngineException for particular errors? I think there's an important case to be made here. I don't think every error belongs having its own subclass, but there are at least a few cases where it may make sense. This list is based off the current PR (1095) and should be seen as incomplete : 1. Argument Mismatch (not passing required parameter, passing invalid parameter, etc) 2. Parse Error (eval, etc) - note this appears to be implemented already 3. Methods On Non-Objects (call to a member function on null) 4. Call to undefined method (this should be a separate exception from ^^^) I also think it *may* be worth while splitting out Class not found and function not found exceptions into their own type, but not 100% sure. Thanks Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On 19/02/15 18:16, Pierre Joye wrote: This is not the point of this discussion. What you referto has to be done for anything PHP uses, every library, every extension or services (http or other). Now read the rest of what I wrote ... Where ever validated data comes from ... it does not need a cast. If it's not validated ... it needs to be before it can be used anyway. Is every variable stored as a string even when it's source is a validated scalar value? -- 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] Using Other Channels (was Scalar Type Declarations v0.5)
Zeev, Based on Sara's clarification in this thread, I owe you a formal apology. I interpreted something she said incorrectly, which was then compounded by messages in private and on-list this morning. I then attributed both of you qualities and motives that have been proven false. For this, I am sorry for any implication or direct acquisition that I made against you. I do believe that the best way forward is parallel proposals, as I believe that we have different goals. So I look forward to seeing yours, and will continue forward with mine. Hopefully this differing of opinion can be rectified before too long. Thanks, Anthony On Thu, Feb 19, 2015 at 9:11 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Thursday, February 19, 2015 4:04 PM To: Zeev Suraski Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) Zeev, That was a quote directly from Sara in a public chat room. It wasn't someone else. So it seems like there was a failure in communication if you felt that it was 100% polite, and she described it as not-so-politely. Ouch. I'm really not sure why she felt that way. I'll follow up with her to try and understand. Then that's great! But let's find that out by voting rather than guessing, and rather than politicking. Let's let two competing proposals go head to head. I'd rather find out by first discussing the alternative, rather than just moving ahead to a revote - especially a revote that was placed on a shortened timeline - given the importance of this RFC. But as you clearly disagree, it's your call to make and I respect that. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Hi! So rather than go for the 70-75% consensus that we **know** we have, How we magically know that? We have the (unfinished) vote, which has a tiny bit over 66% for the proposal. Where 75% comes from? I created a forked RFC. You can keep her as lead all you want, that doesn't mean I can't move forward with my RFC. I think it would really be better to have a lot less us vs them and a bit more cooperative spirit here. That's fine. Let's let the votes decide rather than relying on strongarming. And cooperation means a bit more than we've got 66% so we don't care about anything else. Saying a problem doesn't exist doesn't make it go away. Except if it really doesn't exist, so there's nothing to go away :) -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Stas, I created a forked RFC. You can keep her as lead all you want, that doesn't mean I can't move forward with my RFC. I think it would really be better to have a lot less us vs them and a bit more cooperative spirit here. That ignores the mail that spawned this thread (and the one I got in private) saying in no uncertain terms I shouldn't open a proposal (and should abandon this one) because someone else was working on one. It goes both ways. And sometimes the best way to cooperate is to compete. That doesn't mean we're enemies. It means we have different ideas. So we let the ideas stand for themselves, away from ourselves. That's fine. Let's let the votes decide rather than relying on strongarming. And cooperation means a bit more than we've got 66% so we don't care about anything else. Again, please don't twist words. The point was there exists a proposal which I believe can pass by a supermajority (and nearly did the first time). Why should that be abandoned because some people disagree with it? People disagree with proposals all the time. The way we've agreed to solve that is voting. So isn't that the proper way forward? I don't care if this proposal fails. If it's voted no, that's fine. I think it has a shot to pass though, so shouldn't it be given a fair chance? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
On Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd dan...@basereality.com
wrote:
On 13 February 2015 at 23:25, Nikita Popov nikita@gmail.com wrote:
Subclassing: Should there be more specific subclasses of EngineException
for particular errors?
It's not obvious that any subclasses would be useful. However using
the code to specify the exact type of error, rather than having to
inspect the message would be good.
Should EngineException inherit from Exception (and as such be
subject to catch(Exception)) or should we introduce some kind
of special super-class that is not caught by default
Even ignoring the BC problem with having EngineExceptions extending
Exception, I think the EngineException needs to be in a different
hierarchy to Exception to be able to write reasonable code in the
future
Without having EngineException in a separate hierarchy of exceptions,
the code below will catch exceptions where the data is 'ok' but there
was a problem with the code, and continue to process items. This is
almost certainly not the correct behaviour when an EngineException has
been encountered.
interface Service {
function foo($item);
}
function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service-foo($item);
}
// Because $service can throw an Exception that is specific to the
// implementation we have to catch \Exception, unless we are going
// to list all possible implementation specific exception types here.
// That would be a subtle case of strong coupling, and when a new
// implementation is made the new exception type would need to
// be added here.
catch(\Exception $e) {
// item was not processable but PHP engine is OK.
$item-markAsErrored();
//Go on to process the next item
}
}
}
To avoid having EngineExceptions in a separate hierarchy, this
function could be converted to:
function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service-foo($item);
}
catch(\EngineException $ee) {
//PHP engine is not stable - lets get out of here.
throw $ee; //or throw new ProcessException($ee)
}
catch(\Exception $e) {
$item-markAsErrored();
}
}
}
However that is bad as i)it's boiler plate to do the correct behaviour
ii) you have to remember to do that everywhere. Having to remember to
do the correct thing, is going to lead to people forgetting.
It will still be necessary to catch all types of Exception in a single
catch block i.e. at the top level of a script to prevent exceptions
being shown to the end user. This could be made easier by having a
common super class for Exception and EngineException. However having
one try block that is required to have multiple catch statements to
catch all different types of exception is not that much of a burden:
try {
runApp();
}
catch(EngineException $e) {
handleException($ee);
}
catch(Exception $e) {
handleException($e);
}
As that would be the only place it would be required to catch both types.
TL:DR EngineException needs to not extend Exception, whether we need a
super class is not as clear.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I think we may introduce the following hierarchy
abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}
the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)
Thanks. Dmitry.
Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
On 19/02/15 01:33, Christoph Becker wrote: Lester Caine wrote: On 18/02/15 23:09, Christoph Becker wrote: It seems to me that this behavior is hard to deal with generally for programmers as well as static analyzers. Andreas' bigint RFC[1] would solve that issue, but it has been withdrawn, and AFAIK nobody is working on it. OTOH, bigint would make the widening from int to float potentially even more lossy (i.e. inaccurate) than it is now (64bit ints vs. IEEE 754 doubles). The 'unconstrained integer' RFC adds it' own problems, but the int - float overflow is only a problem with 32bit builds anyway. 64bit builds will not overflow until they run out of space anyway. It seems to me you're thinking too much (maybe only?) about database types. IMHO PHP can be used more versatile, and there might be issues which are exemplified in the RFC[1]: var_dump(2 ** 64); // float(1.844674407371E+19) Clearly an int-float overflow that'll also happen on 64bit builds. [1] https://wiki.php.net/rfc/scalar_type_hints_v5#integer_overflow_to_float_behavior You see this has nothing to do with 'Scalar Type Declarations' ... this is a problem in it's own right that needs sorting as part of the general 64bit 'upgrading' and providing a proper fix for 64bit numbers is something which the 'unconstrained integer' RFC addressed but in my book it was always the wrong fix, and providing a cross platform fix for BIGINT which provides a simple integer value is the correct fix. The voting on that RFC seemed to agree. We need 64bit values in several places where simply clipping to 32bit ones is no longer the correct fix. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
On 19/02/15 04:44, Dennis Birkholz wrote: I just saw the reddit where you mention that v0.4 is practically abandoned now, so I will just renounce my previous mail! DO NOT USE OTHER CHANNELS! With the large number of secondary channels the only place that suggestions like that should be made is here and as far as I have seen both ideas are still 'active'? But I do find it crass that there is now a different document with no reference to the v4 history! What does need unravelling is just which bits go with which discussion across all of the areas. I'm still looking at how any of this applies to the values in the arrays I'm passing around and just getting more and more confused. What I think I want is a set of functions to replace all this casting mess. Rather than is_bool ... as_bool similarly as_int64 rather than getting an automatic float. I want to ask to look at a variable in the array as the type I need for the job in hand now you may say that is 'casting' but you are not providing me with the casts *I* and many other database users need. I can see the 'advantage' of optimizing code via this strict stuff that some people want, but I don't see that has any place in a 'run only' version of PHP. If you want to compile the code then use a port of PHP that is compiled. Leave those of use who prefer the more dynamic system which may well have to deal differently with a scalar variable depending on what is returned at runtime. On the minus side of this drive to 'optimize' the code is the potential for completely different code on 32bit systems over 64bit ones. If the number is below 32bit then a completely different set of code gets used using only 32bit instructions. This may well be good for speed, but can introduce cross platform differences that may be difficult to debug. We currently live with those problems already with the int-float agro on 64bit numbers. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 19 Feb 2015, at 12:54, Dmitry Stogov dmi...@zend.com wrote:
I think we may introduce the following hierarchy
abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}
the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)
If I remember it correctly, BaseException was used by some real code out there.
But we can use _BaseException instead
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston tonymars...@hotmail.com
wrote:
Rowan Collins wrote in message news:54e4fac2.7060...@gmail.com...
Tony Marston wrote on 18/02/2015 10:52:
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it
could be a permissions error, for example). Is there any plan to convert
procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
So, no, since that's currently an E_WARNING, there is no current plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.
That has absolutely nothing to do with OO vs procedural code, though.
A procedural function could well have an error condition which should be
fatal if unhandled, but can usefully be caught somewhere up the stack,
which is basically what an exception is for. Any procedural function
which
currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to be
converted under the current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists with
some other functions as well, so it would be nice to be able to put the
function in a try . catch block so that any and every message could
be
made available. It is quite obvious that changing fopen() to use
exceptions
would be a major BC break for all exiting applications, so my question is
this:
Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not then
don't throw an exception. I realise that this might be tricky to
implement,
but if it could be it would allow the developer to choose whether he/she
wanted to use exceptions or not instead of having the choice forced upon
him/her.
Is this possible? Or am I just dreaming?
The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call in a try ... catch block for
the purposes of that check, or not? If putting try { ... } around an entire
application caused all calls to fopen(), in every library it used, to stop
returning false, you'd have exactly the same BC issue as just changing it
permanently.
function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}
function load_data() {
$fh = fopen(...);
...
}
So no, I'm afraid it's probably not possible.
Regards,
Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within *that* function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.
If the exception is only thrown when the try - catch is in the same
scope, is there really much advantage to it being an exception? When you're
that close to the code, sticking an if ( $fh === false ) { ... } around it
really isn't that much different from catch(IOException $e) {
The advantage is that you can obtain the reason for the error. All that
happens with fopen() at the moment is that it returns FALSE which tells you
that it has failed, but it does not tell you why. This is a classic example
of the semipredicate problem for which exceptions were originally designed.
The main advantage is the ability to catch FATAL errors that previously
leaded to script termination and 500 response.
Thanks. Dmitry.
Having the problem be detectable in a higher scope is kind of the point
of exceptions.
So is the ability of catching an exception immediately it is thrown so
that you can obtain the error message. Having the ability to deal with an
exception at a higher level is only relevant if you don't deal with it
immediately, either by design or by accident.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 19/02/15 09:13, Zeev Suraski wrote: Obviously, I think 'weak' campers have a lot to gain too - by making sensible conversions work fine as expected, without having to resort to explicit casts. And everyone stands to gain from having just one mode, instead of two. The coercive typing approach would require each camp to give up a bit of their 'ideology', but it also gives both schools of thought *most* of what they want, including the key tenets for each camp (rejecting non-sensible conversions - always, allowing sensible ones - always). I believe that's what makes it a good compromise, a better one than the currently proposed RFC. Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
De : Lester Caine [mailto:les...@lsces.co.uk] On 19/02/15 04:44, Dennis Birkholz wrote: I just saw the reddit where you mention that v0.4 is practically abandoned now, so I will just renounce my previous mail! DO NOT USE OTHER CHANNELS! Agreed. And the RFC was not abandoned at all. I and others have been working almost continuously on a 'compromise' single-mode approach during the last 3 days (and nights), as activity on the list shows with no doubt. So, pretending the RFC to be 'abandoned' is just a way to discard a disagreed work. As long as she does not officially gives up (posting to the list), I'll keep considering Sara still has the lead on scalar type hinting. If she officially gives up, I'll immediately propose to take it over and, if we are several to want it, we'll discuss. That's the rule and I encourage list members to explicitly show their support to the formal process we all agreed upon. For the rest, Lester summarized quite well my view about designing PHP for static analysis, instead of static analysis for PHP ;) Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Le Thu Feb 19 2015 at 00:38:25, François Laupretre franc...@php.net a écrit : Why can't strictness follow that path? Because strictness is not the overall objective the PHP language is aiming to. I cannot agree more with that. If it was the case, your mechanism would be fine, but deprecating ZPP conversion would be simpler and fine too. I'm not so sure about the simpler. This is definitely not the same case as generating a notice on array to string. Sure, I just wanted to pinpoint that because strictness is not the overall objective of the PHP language, we may consider a weak approach accompanied by an activable (configurable?) mechanism that would notices us of bad types, bad coercion, conversion with loss,... That's what I hate in this 'weak' vs 'strict' terminology. It makes implicit that 'strict' is the natural future and improvement of 'weak'. That's absolutely not the case as 'weak' mode is not as negative as name suggests, and 'strict' is not so positive either. So, you may stop considering that the natural path for 'weak'-typed software is to migrate to strict types. I never implied something like this, quite the opposite since I feel I am completely aligned with you! When we decide encouraging migrating to strict mode with a deprecation on ZPP conversion, I hope I'll be far away... +1 PS: your feedback makes me feel it would be; even more; a viable option :) Fine. But may I remind you the so-called great benefit you underlined in your post is totally wrong and shows total ignorance of the difference between casting and ZPP conversion rules which, IMO, is a fundamental pre-requisite before laughing at people working on this. I never laughed at any one here. Sorry if someone felt that way by the simple use of a smiley.
RE: [PHP-DEV] Scalar Type Hints v0.4
Hi Patrick, We already plan a similar mechanism by raising an E_DEPRECATED on conversions that would have succeded in PHP 5 and will fail using the proposed new ‘PHP 7’ ZPP ruleset. Then, it is technically possible to raise a notice on non-strict conversion but it must be discussed in depth because it can be very confusing, as E_NOTICE or, even, E_STRICT, are typically associated with ‘bad practice’, and that’s not the case here. So, a lot of people would assume these as something ‘clean’ code should avoid. Maybe another error type could be needed, but I don’t see the need as so important. Regards François De : Patrick ALLAERT [mailto:patrickalla...@php.net] Envoyé : jeudi 19 février 2015 11:07 À : franc...@php.net; Sara Golemon Cc : PHP internals Objet : Re: [PHP-DEV] Scalar Type Hints v0.4 Le Thu Feb 19 2015 at 00:38:25, François Laupretre franc...@php.net a écrit : Why can't strictness follow that path? Because strictness is not the overall objective the PHP language is aiming to. I cannot agree more with that. If it was the case, your mechanism would be fine, but deprecating ZPP conversion would be simpler and fine too. I'm not so sure about the simpler. This is definitely not the same case as generating a notice on array to string. Sure, I just wanted to pinpoint that because strictness is not the overall objective of the PHP language, we may consider a weak approach accompanied by an activable (configurable?) mechanism that would notices us of bad types, bad coercion, conversion with loss,... That's what I hate in this 'weak' vs 'strict' terminology. It makes implicit that 'strict' is the natural future and improvement of 'weak'. That's absolutely not the case as 'weak' mode is not as negative as name suggests, and 'strict' is not so positive either. So, you may stop considering that the natural path for 'weak'-typed software is to migrate to strict types. I never implied something like this, quite the opposite since I feel I am completely aligned with you! When we decide encouraging migrating to strict mode with a deprecation on ZPP conversion, I hope I'll be far away... +1 PS: your feedback makes me feel it would be; even more; a viable option :) Fine. But may I remind you the so-called great benefit you underlined in your post is totally wrong and shows total ignorance of the difference between casting and ZPP conversion rules which, IMO, is a fundamental pre-requisite before laughing at people working on this. I never laughed at any one here. Sorry if someone felt that way by the simple use of a smiley.
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Dennis,
Will you consider to let the people vote on how to enable strict mode
like discussed in the v0.4 discussion? Like this here from the Reviving
scalar type hints thread?
I believe that RFCs should be opinionated. I dislike the recent trend
around having a lot of voting options as it only complicates things
for the voter.
For this reason I have chosen what I think is technically the best
option and went from there. I am definitely open to changing that, but
it would need to be based on technical reasons and not just popular
preference. Heck, in a recent public poll, over 20% of respondents
voted for it being an ini setting.
I touched on the reasons in the RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5#why_not_use_use_strict_instead_of_declare
But let me go through them one-by-one:
Am 17.02.2015 um 00:58 schrieb Sara Golemon: Straw poll:
1) ?php strict;
This is new syntax, which is potentially ambiguous around what
strictness is being applied. It limits future compatibility.
Additionally, it's potentially ambiguous if a file starts with ?=
strict; 4; ?. Is that setting strict mode for a file and outputting
4? Or is it outputting the constant strict? Sure, this could be
solved with a rule that it could only follow ?php, but that starts
to get arbitrary and potentially confusing, given the other ways to
open PHP tags.
2) ?php-strict
STRONG -1, as it leaves potential for code disclosure if run on a
earlier version of PHP.
3) use strict; (psuedo-namespace)
Re-using namespaces to effect runtime is weird. Not to mention what's
the expected behavior of block mode:
?php
namespace Foo {
use strict;
}
namespace {
bar();
}
?
is bar() called in strict mode? Or in non-strict mode?
4) ?php // strict (I don't actually like HHVM's style, but if you do...)
Comments should not affect runtime behavior. HHVM uses it as they need
to affect behavior while remaining compatible with PHP. We do not have
that problem.
5) declare(strict=true); (As a top-level declare only)
6) declare(strict=true); (exactly as in v0.3 -- maybe you liked it)
Which had a number of people against it, with arguments about the odd
behavior of declare in blocks, etc.
7) your write-in vote here
The only other one I've seen that *might* make sense is using a strict
qualifier on the namespace declaration:
strict namespace Foo {
}
IMO this has the same issues as use strict above. However, it also
seems to imply that the namespace is strict, where it's only the
declarations in the file that are.
I'm 100% open to technical arguments and justification to switch to
another syntax. I don't believe that it should be a poll though.
That's why I made a decision and backed it up. If anyone has logical
arguments or disagrees, let's discuss it. That way the proposal can be
improved through collaboration rather than just a blind vote.
Thanks for the feedback!!!
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Digit separators for numeric literals
On 19/02/15 13:16, Nikita Nefedov wrote: Why not space? It's certainly possible (I just checked) and it would look clear I guess: my_func(1 999 999); Yes, but what if I just missed one or two commas there? ;) -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC][DISCUSS] Continue output buffering despite aborted connection
Hi, I drafted an RFC to continue output buffering despite an aborted connection was detected. The title might well be a bit misleading, so please read the RFC before judgement. https://wiki.php.net/rfc/continue_ob -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Zeev, On Thu, Feb 19, 2015 at 8:52 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Thursday, February 19, 2015 3:24 PM To: franc...@php.net Cc: Lester Caine; internals@lists.php.net Subject: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) Let me quote something that was said: Ze'ev and François have not-so-politely asked [Sara] to not put 0.4 forward since they have something they believe they have consensus on. Anthony, Please stop this. I have been in touch with Sara, yes, but it was absolutely and 100% polite, which I'm sure she'll confirm if you ask her. I can't speak for François as I wasn't a part of whatever correspondence they had between them. And no, quoting someone else instead of you making that statement and doesn't make it any better. That was a quote directly from Sara in a public chat room. It wasn't someone else. So it seems like there was a failure in communication if you felt that it was 100% polite, and she described it as not-so-politely. To be clear, the proposal you're pushing as v0.5 is very different from what she had in mind for v0.4, based on the initial discussions on internals. She was trying to listen in to issues and come up with substantial changes to the v0.3 RFC to radically increase the consensus around it. v0.5, on the other hand, is, for the most part, v0.3 with opinionated, discussionless explanations of why it's absolutely fine to keep as-is. Correct. v0.5 is very much in line with 0.3. Because many have been asking for it. Because I truely believe that the discussions that were happening around 0.4 and the other proposals have been moving further away from a good consensus rather than towards it. So I saw what I believe is a good proposal, and moved forward with it, tweaking the few things that I thought had to be tweaked. We had a proposal that *had* consensus (66%). It was withdrawn. 66% is not consensus. It's a form of special majority but by any stretch absolutely not consensus in any definition of the word. I'm not going to refer to your guesstimates you have about your ability to reach consensus with slight modifications to the proposal, but I can say that I know there are at least a few people that voted yes, and in light of the new proposal that's forming up would now vote no, preferring that new option. Then that's great! But let's find that out by voting rather than guessing, and rather than politicking. Let's let two competing proposals go head to head. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Digit separators for numeric literals
2015-02-19 6:44 GMT+04:00 Rasmus Lerdorf ras...@lerdorf.com: I think it will be difficult to find a separator character that doesn't make a mess of the grammar. my_func(1,999,999) obviously doesn't work my_func(1'999'999) as per C++14 clashes with our single-quoted strings my_func(1_999_999) like in ADA might work but _999_ would need to work as well and _ is a valid char in a constant so you can have a constant named _999_. - nope # nope @ nope ~ nope ! nope % nope ^ nope We went through this for the namespace char, and there simply isn't a typable single character left to use for something like this. _ is the closest but it would require some changes and BC breaks which I am not sure is worth for what appears to me to be a not-so critical feature. Now if we went into Unicode territory, we could do it. eg. my_func(1 999 999) U+1680 (although it looks too much like a -) my_func(1 999 999) U+205F (mathematical space) my_func(1٬999٬999) U+066C (Arabic thousands separator) my_func(1·999·999) U+00B7 (middle dot) The last one looks best to me, but we'd need a team of people working in shifts to answer the, How do I type this? question. -Rasmus Hey, Why not space? It's certainly possible (I just checked) and it would look clear I guess: my_func(1 999 999);
RE: [PHP-DEV] Reviving scalar type hints
Hi Lester, I didn't add restrictions specific to number representation in the draft ruleset yet, becausen while I think that's an important point, I didn't have time to study it in depth. I know you're an expert on this as you continuously (rightly) raised the point. So, can you elaborate on this and send me or, better, publish on the list the detailed set of changes you suggest, including 32 bit vs 64 bit concerns if they fit. Today, conversion restrictions are rather limited as floats which don't fit in int give 0, and int to float is considered as always possible. I mean that must be technically incorrect, while unnoticed in the vast majority of cases. So can you write a consistent set of changes you would introduce ? Thanks François -Message d'origine- De : Lester Caine [mailto:les...@lsces.co.uk] Envoyé : jeudi 19 février 2015 11:24 À : internals@lists.php.net Objet : Re: [PHP-DEV] Reviving scalar type hints On 19/02/15 09:13, Zeev Suraski wrote: Obviously, I think 'weak' campers have a lot to gain too - by making sensible conversions work fine as expected, without having to resort to explicit casts. And everyone stands to gain from having just one mode, instead of two. The coercive typing approach would require each camp to give up a bit of their 'ideology', but it also gives both schools of thought *most* of what they want, including the key tenets for each camp (rejecting non-sensible conversions - always, allowing sensible ones - always). I believe that's what makes it a good compromise, a better one than the currently proposed RFC. Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hints v0.4
Le Wed Feb 18 2015 at 19:10:08, François Laupretre franc...@php.net a
écrit :
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
The biggest advantage, IMHO, is that you get the exact same result
whether
you do:
foo((int) $value);
or:
foo($value);
... whatever the mode you are in.
Wrong. Parameter parsing rules are much more restrictive than casting
rules.
Only 'foo((int)'orange')' would (erroneously) succeed.
Francois, I'm very aware of the distinction between cast mechanism and ZPP,
but I obviously haven't been clear about the fact that the
(conversion|coercion|type juggling|...) reporting configuration I proposed
would have to be used in ZPP *AND* casting mechanism (and anywhere else
where some conversion applies).
With:
$value = foo;
foo((int) $value);
it is: (int) $value that would generate a warning/error depending on the
reporting, not while parsing the parameter of function foo(), which would
receive an int (0) in this precise case.
And this would address the cases:
http://example.org/foo.php?id=42
http://example.org/foo.php?id=bar
foo.php:
?php
fetchById(int $id) {
// ...
}
fetchById($_GET[id]);
even if $_GET[id] is replaced by (int) $_GET[id];
Cheers,
Patrick
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Francois and Lester (and all), Please keep this thread on-topic. It should be for technical discussions around this RFC only. If you have something non-technical to discuss, please start a new topic. Thanks Anthony On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre franc...@php.net wrote: De : Lester Caine [mailto:les...@lsces.co.uk] On 19/02/15 04:44, Dennis Birkholz wrote: I just saw the reddit where you mention that v0.4 is practically abandoned now, so I will just renounce my previous mail! DO NOT USE OTHER CHANNELS! Agreed. And the RFC was not abandoned at all. I and others have been working almost continuously on a 'compromise' single-mode approach during the last 3 days (and nights), as activity on the list shows with no doubt. So, pretending the RFC to be 'abandoned' is just a way to discard a disagreed work. As long as she does not officially gives up (posting to the list), I'll keep considering Sara still has the lead on scalar type hinting. If she officially gives up, I'll immediately propose to take it over and, if we are several to want it, we'll discuss. That's the rule and I encourage list members to explicitly show their support to the formal process we all agreed upon. For the rest, Lester summarized quite well my view about designing PHP for static analysis, instead of static analysis for PHP ;) Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Reviving scalar type hints
-Original Message- From: Lester Caine [mailto:les...@lsces.co.uk] Sent: Thursday, February 19, 2015 12:24 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Reviving scalar type hints On 19/02/15 09:13, Zeev Suraski wrote: Obviously, I think 'weak' campers have a lot to gain too - by making sensible conversions work fine as expected, without having to resort to explicit casts. And everyone stands to gain from having just one mode, instead of two. The coercive typing approach would require each camp to give up a bit of their 'ideology', but it also gives both schools of thought *most* of what they want, including the key tenets for each camp (rejecting non-sensible conversions - always, allowing sensible ones - always). I believe that's what makes it a good compromise, a better one than the currently proposed RFC. Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? I think the guiding principal for these conversions should be no data loss. This may mean we have different limits on different architectures, depending on whether they're 32-bit or 64-bit. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Hello Anthony, Am 19.02.2015 um 14:01 schrieb Anthony Ferrara: I believe that RFCs should be opinionated. I dislike the recent trend around having a lot of voting options as it only complicates things for the voter. I just thought giving a vote on how to enable strict mode would enable a few more people to actually vote yes. I myself can not vote but I really hope we get scalar type hints in what kind soever into PHP 7. So keep on and thank you for taking over. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Digit separators for numeric literals
Rasmus Lerdorf wrote: On 02/18/2015 11:21 PM, Rick Widmer wrote: how about: my_func( '1,000.04' ); //if you want to use separators there. The problem with that is that the world is split. The other half, or actually more than half, would write that as '1.000,04'. There is no way we would want to take sides on that one. And we have support for locale-based number formatting and parsing via numfmt_format() and numfmt_parse(). If we were going to add a separator for literals, the only real low-ascii choice is _ which is also used by Ada, D, Java, Perl and Ruby. I agree that _ is most reasonable, mainly because it is used by other languages also. I was 90% kidding about using a Unicode character, but if you think about it a bit, most people are using IDEs or at least smart scriptable editors, it wouldn't be that much of a stretch to picture your editor pretty-printing 1234567890 as 1·234·567·890 or 1˙234˙567˙890 (U+02D9). It would be easy to make the parser ignore that character in numeric literals. Much easier than working out the various issues with _ anyway. Which issues do you see? IMHO it doesn't make much sense to use a digit separator in a trailing or leading position, because that wouldn't improve readability. So PHP could make the same restrictions as Java with regard to integer and float literals[1] (basically that the underscore is allowed only between actual digits), in which case I don't see any syntactic ambiguity. Ignoring the _ in the scanner (IMHO there is no need to obtain it in the token) doesn't seem to be harder than ignoring any other character. [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Francois On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre franc...@php.net wrote: De : Lester Caine [mailto:les...@lsces.co.uk] On 19/02/15 04:44, Dennis Birkholz wrote: I just saw the reddit where you mention that v0.4 is practically abandoned now, so I will just renounce my previous mail! DO NOT USE OTHER CHANNELS! Agreed. You mean like contacting another contributor in private asking them to not make a proposal and to stop work on it? And the RFC was not abandoned at all. I and others have been working almost continuously on a 'compromise' single-mode approach during the last 3 days (and nights), as activity on the list shows with no doubt. So, pretending the RFC to be 'abandoned' is just a way to discard a disagreed work. Let me quote something that was said: Ze'ev and François have not-so-politely asked [Sara] to not put 0.4 forward since they have something they believe they have consensus on. So while it may not have been abandoned, it was sandbagged (sabotaged, strong-armed, etc). I used abandoned as a light term to not point out to list what strong-arming happened behind the scenes. But since you apparently don't want other channels used... I can't stress how deplorable that act is. How harmful to the community it is to ask in private for a contributor to stop what they are doing because someone else has a better idea. We had a proposal that *had* consensus (66%). It was withdrawn. With some minor changes, at least 25% of no-voters would have changed their mind (based on conversations around why the voted no). So rather than go for the 70-75% consensus that we **know** we have, we should drop all work for a magic vaporware proposal. Contributors should stand down and not contribute because you know better. I'm sorry, I favor the proposal that's in writing and implemented rather than one that's yet to be seen. If yours does indeed prove to be as good as possible, then the votes will decide. Or if it convinces me early enough, I'll withdraw the current proposal. But based on everything I've seen in the discussion threads, I can't possibly see how that will happen. I hope you surprise me, but in case that you don't, I'm moving forward with the existing implementation that we know has support. As long as she does not officially gives up (posting to the list), I'll keep considering Sara still has the lead on scalar type hinting. If she officially gives up, I'll immediately propose to take it over and, if we are several to want it, we'll discuss. I created a forked RFC. You can keep her as lead all you want, that doesn't mean I can't move forward with my RFC. That's the rule and I encourage list members to explicitly show their support to the formal process we all agreed upon. What rule is that? Can you point me to anywhere in the Voting RFC that says that? https://wiki.php.net/rfc/voting It doesn't. That's fine. Let's let the votes decide rather than relying on strongarming. For the rest, Lester summarized quite well my view about designing PHP for static analysis, instead of static analysis for PHP ;) Saying a problem doesn't exist doesn't make it go away. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: (off topic) Array to string conversion (Was: Re: [PHP-DEV] Scalar Type Hints v0.4)
2015-02-19 12:26 GMT+01:00 François Laupretre franc...@php.net: Hi Patrick, I know you didn’t decide it alone, but the right solution, IMO, would have been to E_DEPRECATE nonsense conversions. That’s what we are currently doing for ZPP conversions (https://wiki.php.net/rfc/zpp-conversion-rules). I also proposed this for array to string (https://wiki.php.net/rfc/array-to-string) but should probably extend it to other conversions that generate E_NOTICE, at least. For a new major version, it perfectly make sense and I am with you on refactoring this. Take into account that casting an object (without __toString() implementation) to string will generate an E_RECOVERABLE_ERROR (at one moment [1], it generated the string Object! That was quickly change to generate an error, but the array to string conversion did not benefit of the same change and survived much longer). As you suggest, I think it would be good to extend it to other conversions so that it might be unified a bit. [1] https://github.com/php/php-src/commit/da9faa2c3a7db0f222e751e899c843a1f6561e8b#diff-b09edfedd835ebc4491e565c147190e7R133 Thanks, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Thursday, February 19, 2015 3:24 PM To: franc...@php.net Cc: Lester Caine; internals@lists.php.net Subject: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) Let me quote something that was said: Ze'ev and François have not-so-politely asked [Sara] to not put 0.4 forward since they have something they believe they have consensus on. Anthony, Please stop this. I have been in touch with Sara, yes, but it was absolutely and 100% polite, which I'm sure she'll confirm if you ask her. I can't speak for François as I wasn't a part of whatever correspondence they had between them. And no, quoting someone else instead of you making that statement and doesn't make it any better. So while it may not have been abandoned, it was sandbagged (sabotaged, strong-armed, etc). I used abandoned as a light term to not point out to list what strong-arming happened behind the scenes. But since you apparently don't want other channels used... I can't stress how deplorable that act is. How harmful to the community it is to ask in private for a contributor to stop what they are doing because someone else has a better idea. Strong-arming, sabotaging... Absolute nonsense, and offending nonsense at that. I, for one, didn't ask her to stop what she was doing. I try to get her opinion of an alternative which I - and many others - believe is better. I'll let her decide whether she wants to disclose her reply, but I can quote her public tweet, which I'm sure you've seen: @ircmaxell @andrerom @trevorsuarez @zeevs @rasmus ftr, I'm deferring to a couple of other proposals on the table. Doesn't need to be mine. There's absolutely nothing deplorable about talking to Sara off list. As I told her in my email, I wanted to first gauge her opinion about that proposal and see if she was willing to support it. I did not push her to abandon v0.4. To be clear, the proposal you're pushing as v0.5 is very different from what she had in mind for v0.4, based on the initial discussions on internals. She was trying to listen in to issues and come up with substantial changes to the v0.3 RFC to radically increase the consensus around it. v0.5, on the other hand, is, for the most part, v0.3 with opinionated, discussionless explanations of why it's absolutely fine to keep as-is. We had a proposal that *had* consensus (66%). It was withdrawn. 66% is not consensus. It's a form of special majority but by any stretch absolutely not consensus in any definition of the word. I'm not going to refer to your guesstimates you have about your ability to reach consensus with slight modifications to the proposal, but I can say that I know there are at least a few people that voted yes, and in light of the new proposal that's forming up would now vote no, preferring that new option. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On Thu, Feb 19, 2015 at 5:52 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Thursday, February 19, 2015 3:24 PM To: franc...@php.net Cc: Lester Caine; internals@lists.php.net Subject: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) Let me quote something that was said: Ze'ev and François have not-so-politely asked [Sara] to not put 0.4 forward since they have something they believe they have consensus on. Anthony, Please stop this. I have been in touch with Sara, yes, but it was absolutely and 100% polite, which I'm sure she'll confirm if you ask her. I can't speak for François as I wasn't a part of whatever correspondence they had between them. And no, quoting someone else instead of you making that statement and doesn't make it any better. Zeev, You are smart enough to understand what has been said here. We have seen off list discussions or pressures many times in the pasts. I have (other too but I can only talk for myself) been said an insane amount of times to stop private discussions, for anything related to php core. There is no exception to this rule. I repeat: There is NO exception to this rule. This is what killed cooperation, it was what make PHPNG a bad thing to begin with, no matter the promises it brought. While we got over it and push it forward in the meantime, trying to stay positive. The bad thing with the acceptance of it is that you may feel that what has been done and how it has been done is all good. That the community does not care. let me tell you, I do care. And many do. What happened and is still happening damage the core communities around PHP. Feel free to ignore this message, but that does not make any of the recent events look better. And expect an open letter soon. Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Digit separators for numeric literals
On 02/18/2015 11:49 PM, Michael Wallner wrote: On 19/02/15 03:44, Rasmus Lerdorf wrote: but _999_ would need to work as well and _ is a valid char in a constant so you can have a constant named _999_. Why would we need to support the underscore in front (and maybe even at the end) of a number? I guess we could restrict it to not be leading. I was thinking along the lines of the character being defined to be ignored anywhere in a literal. The underscore was actually rejected in C++14 because C++ has user defined literals. http://en.cppreference.com/w/cpp/language/user_literal which would then make 0x12_ab problematic. We obviously don't have user-defined literals so we probably could make it work. Like I said, that is the only viable option as far as I can see. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] RFC: Expectations
Hi Joe, I think, we may just add additional vote question. - If we like to custom exceptons as second argument? but I don't care about it, so do as you like. According to AssertException: add a note into Open Issues section. e.g. we may introduce new abstract class BaseException then make Excepton to be a child of BaseException then introduce and use for assert AssertException (direct child of BaseException) All this changes are going to be implemented as part of Engine Exception RFC. And open the vote. Thanks. Dmitry. On Thu, Feb 19, 2015 at 10:58 AM, Joe Watkins pthre...@pthreads.org wrote: Morning, I hear the concern regarding custom exceptions. Things will be used badly whatever. It's easy to imagine that in a simple application you just don't need to specify custom exceptions. But in a large codebase, being able to structure exceptions is invaluable, it gives documentation reference points and makes stack traces easier to read at a glance, because they are more meaningful. So I think we should keep the ability to throw custom exceptions. I agree about making the exception part of a new tree, so that they are not caught, so I'll just wait for that from dmitry and open the vote. Cheers Joe On Wed, Feb 18, 2015 at 5:01 PM, Dmitry Stogov dmi...@zend.com wrote: On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. I've added a few comments on the PR. Thank you very much. You found about 25 bugs :) All of them except for elseif should be fixed now. I also think printing else if instead of elseif is not a big problem. Pretty-printer may also add or remove brackets in some situations. Two general notes on the RFC: 1. I don't like the ability to specify a different exception as the second param. Assertions are supposed to be used as sanity checks during development, not to throw meaningful and specialized exception types. Having this possibility will probably only encourage bad usage of assert(). It's not a big problem to me, but I'd rather not have this feature. Joe, this is part of your old patch. I really don't care about it. 2. Similar to the EngineExceptions RFC I'm wondering if AssertionException should extend Exception or be in a separate hierarchy. The same argument as with engine exceptions applies: It's pretty unlikely that you want to catch an AssertionException anywhere apart from top-level error handling code and that people using catch(Exception) blocks would accidentally catch assertions. I'm not sure I agree with this, but I wanted to mentioned the concern. This may be changed together with EngineException patch. I started working on it, and I hope I'll show you results tomorrow. Thanks. Dmitry. Nikita
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
On Thu, Feb 19, 2015 at 12:50 AM, Anthony Ferrara ircmax...@gmail.com wrote: Leigh, Internal Functions Like ceil() Return Unexpected Types My opinion is that functions should return sane types for their intended purpose, and functions that do not should be fixed. I agree 100%. I just think that's outside the scope of this proposal. Static Analysis Is Possible With Weak Declarations The advocacy of allowing `accepts_float(returns_int());` doesn't help the cause of static analysers in strict mode. Java does exactly this and is statically analyzable. So...? PHP is not a language for static analyzes or verification!!! Strict typing shouldn't be done on language level. it may be implemented as a custom verification extension, but please, don't break the language itself. Thanks. Dmitry. Still no mention of a way to enable strict by default. So lets try some different rationale. If I personally want to develop in strict mode, I can do that with this proposal, I can add a declare to the top of every file and be as strict as I like. However not everyone else is going to want to use my code in strict mode, so they will have to go and remove some/all of those strict declarations. (Lets take callbacks being evaluated in the context they are called rather than the one they are created in). I would like a way of enabling strict by default, immutable to scripts so that users cannot be forced into this mode, and lets the radicals and the weaklings* play together in harmony. I missed that discussion point, so I've just added it: https://wiki.php.net/rfc/scalar_type_hints_v5#why_not_add_an_ini_setting_for_default_mode For the rest of the RFC, I either agree with or have no strong opinions about the points raised. Thanks for the input :-) Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
I think that structure makes sense Dmitry.
Though, just a bit on naming here (I know, its not a big deal, and naming
is hard, haha):
I think that naming the new parent exception something like Throwable or
Catchable (as Nikita previously suggested) would be a bit more concise in
meaning than BaseException. You may not have even meant that name as a
formal proposal, but I figured I'd weigh in regardless. :P
- Trevor
On Thu Feb 19 2015 at 4:55:38 AM Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd dan...@basereality.com
wrote:
On 13 February 2015 at 23:25, Nikita Popov nikita@gmail.com wrote:
Subclassing: Should there be more specific subclasses of
EngineException
for particular errors?
It's not obvious that any subclasses would be useful. However using
the code to specify the exact type of error, rather than having to
inspect the message would be good.
Should EngineException inherit from Exception (and as such be
subject to catch(Exception)) or should we introduce some kind
of special super-class that is not caught by default
Even ignoring the BC problem with having EngineExceptions extending
Exception, I think the EngineException needs to be in a different
hierarchy to Exception to be able to write reasonable code in the
future
Without having EngineException in a separate hierarchy of exceptions,
the code below will catch exceptions where the data is 'ok' but there
was a problem with the code, and continue to process items. This is
almost certainly not the correct behaviour when an EngineException has
been encountered.
interface Service {
function foo($item);
}
function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service-foo($item);
}
// Because $service can throw an Exception that is specific to the
// implementation we have to catch \Exception, unless we are going
// to list all possible implementation specific exception types here.
// That would be a subtle case of strong coupling, and when a new
// implementation is made the new exception type would need to
// be added here.
catch(\Exception $e) {
// item was not processable but PHP engine is OK.
$item-markAsErrored();
//Go on to process the next item
}
}
}
To avoid having EngineExceptions in a separate hierarchy, this
function could be converted to:
function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service-foo($item);
}
catch(\EngineException $ee) {
//PHP engine is not stable - lets get out of here.
throw $ee; //or throw new ProcessException($ee)
}
catch(\Exception $e) {
$item-markAsErrored();
}
}
}
However that is bad as i)it's boiler plate to do the correct behaviour
ii) you have to remember to do that everywhere. Having to remember to
do the correct thing, is going to lead to people forgetting.
It will still be necessary to catch all types of Exception in a single
catch block i.e. at the top level of a script to prevent exceptions
being shown to the end user. This could be made easier by having a
common super class for Exception and EngineException. However having
one try block that is required to have multiple catch statements to
catch all different types of exception is not that much of a burden:
try {
runApp();
}
catch(EngineException $e) {
handleException($ee);
}
catch(Exception $e) {
handleException($e);
}
As that would be the only place it would be required to catch both types.
TL:DR EngineException needs to not extend Exception, whether we need a
super class is not as clear.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I think we may introduce the following hierarchy
abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}
the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)
Thanks. Dmitry.
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
2015-02-19 17:14 GMT+02:00 Pierre Joye pierre@gmail.com: On Thu, Feb 19, 2015 at 7:11 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: I think this starts to go the route of putting things into absolute. Ideal things tend not to happen/work in the real world to the letter. Some things just don't work out by themselves. The Type Hinting RFC's are an anomaly in the regular PHP Core workflow and need some creative handling. No it is not an anomaly but a standard way for some since too long. And we need to fix this. I meant it in a way that no other RFC has failed so many times or had so much misunderstanding or divide. Sometimes it is required to ditch the preferences of people and do stuff for the greater good. Right now I see most people (not all) pushing their own agendas not really giving a damn over the big picture, the timeline and the fact that at this moment RFC already too late for 7.0 according to the Release Process RFC - they cannot be discussed and voted before the feature freeze. Yes, it can be pushed rather easily, but it means breaking the release process RFC again. See the pattern here? And we have the 0.4 version still being made, so it means it will be out for discussion probably next week. Or may not.
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
On Thu, Feb 19, 2015 at 6:14 PM, Trevor Suarez ric...@gmail.com wrote:
I think that structure makes sense Dmitry.
Though, just a bit on naming here (I know, its not a big deal, and naming
is hard, haha):
I think that naming the new parent exception something like Throwable or
Catchable (as Nikita previously suggested) would be a bit more concise in
meaning than BaseException. You may not have even meant that name as a
formal proposal, but I figured I'd weigh in regardless. :P
We thought about Throwable or Catchable interface, but this change
would require more changes and will make more BC breaks.
Thanks. Dmitry.
- Trevor
On Thu Feb 19 2015 at 4:55:38 AM Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd dan...@basereality.com
wrote:
On 13 February 2015 at 23:25, Nikita Popov nikita@gmail.com
wrote:
Subclassing: Should there be more specific subclasses of
EngineException
for particular errors?
It's not obvious that any subclasses would be useful. However using
the code to specify the exact type of error, rather than having to
inspect the message would be good.
Should EngineException inherit from Exception (and as such be
subject to catch(Exception)) or should we introduce some kind
of special super-class that is not caught by default
Even ignoring the BC problem with having EngineExceptions extending
Exception, I think the EngineException needs to be in a different
hierarchy to Exception to be able to write reasonable code in the
future
Without having EngineException in a separate hierarchy of exceptions,
the code below will catch exceptions where the data is 'ok' but there
was a problem with the code, and continue to process items. This is
almost certainly not the correct behaviour when an EngineException has
been encountered.
interface Service {
function foo($item);
}
function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service-foo($item);
}
// Because $service can throw an Exception that is specific to the
// implementation we have to catch \Exception, unless we are going
// to list all possible implementation specific exception types here.
// That would be a subtle case of strong coupling, and when a new
// implementation is made the new exception type would need to
// be added here.
catch(\Exception $e) {
// item was not processable but PHP engine is OK.
$item-markAsErrored();
//Go on to process the next item
}
}
}
To avoid having EngineExceptions in a separate hierarchy, this
function could be converted to:
function processData(array $itemsToProcess, service $service) {
foreach ($itemsToProcess as $item) {
try {
$service-foo($item);
}
catch(\EngineException $ee) {
//PHP engine is not stable - lets get out of here.
throw $ee; //or throw new ProcessException($ee)
}
catch(\Exception $e) {
$item-markAsErrored();
}
}
}
However that is bad as i)it's boiler plate to do the correct behaviour
ii) you have to remember to do that everywhere. Having to remember to
do the correct thing, is going to lead to people forgetting.
It will still be necessary to catch all types of Exception in a single
catch block i.e. at the top level of a script to prevent exceptions
being shown to the end user. This could be made easier by having a
common super class for Exception and EngineException. However having
one try block that is required to have multiple catch statements to
catch all different types of exception is not that much of a burden:
try {
runApp();
}
catch(EngineException $e) {
handleException($ee);
}
catch(Exception $e) {
handleException($e);
}
As that would be the only place it would be required to catch both
types.
TL:DR EngineException needs to not extend Exception, whether we need a
super class is not as clear.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I think we may introduce the following hierarchy
abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}
the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)
Thanks. Dmitry.
Re: [PHP-DEV] [VOTE] Expectations
On Thu, Feb 19, 2015 at 5:47 PM, Markus Fischer mar...@fischer.name wrote: Hi, On 19.02.15 10:09, Joe Watkins wrote: Morning internals, The expectations RFC is now in voting phase: https://wiki.php.net/rfc/expectations#vote - I somehow miss information what the exact differences are to the current implementation, to better judge the impact. The implementation introduces ZEND_ASSERT_CHECK instruction that will jump around calls to assert() depending on zend.assertions ini option. (call and constraint evaluation may be expensive). It's also possible to avoid compilation of asset() at all (setting zend.assertions=-1) This will allow using assert() for program testing, without performance degradation in production. - how does zend.assertions and assert.exceptions work with assert_options() , i.e. isn't the exception behavior meant to be an addition to assert_options() too ? zend.assertions control assert() compilation and execution zend.assertions=-1 zero-cost, assert() won't be compiled at all (including inner code) zend.assertions=0 low-cost, assert() will be compiled but won't be executes (including inner code) zend.assertions=1 assert() wiil be compiled and executed as now - the RFC says: enabled (zend.assertions=1) on development machines, and disabled (zend.assertions=0) in production; a few paragraphs above it says -1 - don't generate any code (zero-cost, production mode). Shouldn't be -1 the default value for production then? With zend.assertions=0 in production, you'll able to switch to zend.assertions=0 at any time. With zend.assertions=-1 of course not. - the RFC says: A call to assert(), without a fully qualified namespace will call assert in the current namespace, if the function exists. An unqualified call to assert is subject to the same optimization configured by zend.assertions. . Does this mean I can control whether a function in a namespace is being optimized-away with when zend.assertion equals -1 and otherwise do my own stuff in there and need to raise an AssertException on my own to signal assertion fails? Yes. you are able to eliminate your own assert() functions in namespaces. Thanks. Dmitry. thank you, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov dmi...@zend.com wrote: On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org wrote: Morning internals, The expectations RFC is now in voting phase: https://wiki.php.net/rfc/expectations#vote I totally miss the Expectation RFC announcement. Where the RFC was actually proposed for discussions. I have been following up the DbC thread, seeing some mentions but that's it. The RFC itself popped up 3 days ago. It's from 2013 Yes, but and it was discussed actively during last week. Still, no announce for a discussion about this specific RFC. And really, the content of the RFC is almost empty, pointing to the ML archive is really not the right way :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, February 19, 2015 4:52 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski z...@zend.com wrote: To discuss at an idea or concept at events and co? Indeed. We all do that. The difference is how to move it to a group discussions and grab other people thoughts to actually get it done, with consensus. The latter part is totally absent using your process. What exactly are we discussing here? My email to Sara yesterday? Or your gripes with how PHPNG was handled? I have no intention to discuss the latter, as it's been beaten to death ages ago; And everything you're bringing up appears to be completely disconnected to the former, which was supposedly the trigger to your email. If it's just an excuse to reopen the PHPNG discussion, I'm not going to play along with it. Focusing on my email to Sara (and several others), there is NOTHING, nothing wrong with a bit of private communications trying to gauge support, opposition, gaps and sort out differences before going for a public discussion. Personally I think it's ridiculous to suggest otherwise, and it's completely equivalent to the stuff you stated 'we all do'. But obviously you're entitled to a different opinion, including one that thinks my position is ridiculous. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On Thu, Feb 19, 2015 at 7:11 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: I think this starts to go the route of putting things into absolute. Ideal things tend not to happen/work in the real world to the letter. Some things just don't work out by themselves. The Type Hinting RFC's are an anomaly in the regular PHP Core workflow and need some creative handling. No it is not an anomaly but a standard way for some since too long. And we need to fix this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
One question just popped up in my mind: what happens if there is a global error handler in place that rethrows errors as exceptions. I heard such a thing suggested pretty often. If not parse errors and other engine errors get thrown as exceptions and are unhandled as such, and that error handler then throws them again - endless recursion? just an idea, maybe not a problem, then sorry. best regards Patrick
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
On 19 February 2015 at 09:54, Dmitry Stogov dmi...@zend.com wrote:
I think we may introduce the following hierarchy
the existing code that caught Exception is going to be unaffected.
We could do that. But it's not obviously correct, and ought to be
justified as to why it would be the correct thing to do.
The problem of people needing to catch every type of exception could
also be solved by using a common interface.
class EngineException implements ExceptionInterface {}
class Exception implements ExceptionInterface {}
try {
foo();
}
catch(ExceptionInterface $exception) {
//catches everything.
}
This avoids a requirement for all exceptions to extend from a common
base class. The interface for exceptions would be the current
Exception classes methods, excluding the constructor.
We thought about Throwable or Catchable interface, but this change
would require more changes and will make more BC breaks.
Please can you explain what those problems are?
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.38 released
Hello! The PHP development team announces the immediate availability of PHP 5.4.38. Seven security-related bugs were fixed in this release, including CVE-2015-0273 and mitigation for CVE-2015-0235. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.38 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.4.38 Stanislav Malyshev PHP 5.4 RM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On Thu, Feb 19, 2015 at 7:21 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, February 19, 2015 4:52 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski z...@zend.com wrote: To discuss at an idea or concept at events and co? Indeed. We all do that. The difference is how to move it to a group discussions and grab other people thoughts to actually get it done, with consensus. The latter part is totally absent using your process. What exactly are we discussing here? My email to Sara yesterday? Or your gripes with how PHPNG was handled? I have no intention to discuss the latter, as it's been beaten to death ages ago; And everything you're bringing up appears to be completely disconnected to the former, which was supposedly the trigger to your email. If it's just an excuse to reopen the PHPNG discussion, I'm not going to play along with it. I am discussion how things should ideally done. I use examples to show why what is currently becoming or already is a standard way to do things is actually causing arms to the project as a whole. Focusing on my email to Sara (and several others), there is NOTHING, nothing wrong with a bit of private communications trying to gauge support, opposition, gaps and sort out differences before going for a public discussion. Personally I think it's ridiculous to suggest otherwise, and it's completely equivalent to the stuff you stated 'we all do'. But obviously you're entitled to a different opinion, including one that thinks my position is ridiculous. I have made my point clear and the recent events show me that I am right to stick to my point, stubbornly and honestly. Nothing you can say will make me think that any of these things were totally fine to be handled this way. So let spare our bored readers some time and bandwidth: I am done with this discussion here. 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] Re: [RFC] Exceptions in the engine
Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.
Thanks. Dmitry.
On Thu, Feb 19, 2015 at 6:31 PM, Dan Ackroyd dan...@basereality.com wrote:
On 19 February 2015 at 09:54, Dmitry Stogov dmi...@zend.com wrote:
I think we may introduce the following hierarchy
the existing code that caught Exception is going to be unaffected.
We could do that. But it's not obviously correct, and ought to be
justified as to why it would be the correct thing to do.
The problem of people needing to catch every type of exception could
also be solved by using a common interface.
class EngineException implements ExceptionInterface {}
class Exception implements ExceptionInterface {}
try {
foo();
}
catch(ExceptionInterface $exception) {
//catches everything.
}
This avoids a requirement for all exceptions to extend from a common
base class. The interface for exceptions would be the current
Exception classes methods, excluding the constructor.
We thought about Throwable or Catchable interface, but this change
would require more changes and will make more BC breaks.
Please can you explain what those problems are?
cheers
Dan
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
2015-02-19 17:41 GMT+02:00 Anthony Ferrara ircmax...@gmail.com: Arvids, I meant it in a way that no other RFC has failed so many times or had so much misunderstanding or divide. No scalar type proposal has made it through a vote. So none of them have technically failed (all except the current one were withdrawn). Technically - agreed, but overall you can see how it may be considered as failed :) Sometimes it is required to ditch the preferences of people and do stuff for the greater good. Right now I see most people (not all) pushing their own agendas not really giving a damn over the big picture, the timeline and the fact that at this moment RFC already too late for 7.0 according to the Release Process RFC - they cannot be discussed and voted before the feature freeze. Yes, it can be pushed rather easily, but it means breaking the release process RFC again. See the pattern here? Well, 0.5, as a minor tweak on 0.3 *could* (by the RFC process) go to vote on the 25th. Which would end on the 11th. A full 4 days before freeze. Without breaking the release process. However, I would be happy to target 7.1 even if the vote passes prior to freeze (assuming an RFC to reserve the scalar type names is proposed and passes, otherwise 8.0). My reason for pushing for the vote is not to get it into 7, but to get it over with. We've been discussing these proposals for years. We have one that came extremely close to passing (save for a few minor issues people voted no to, which are now fixed). Let's get it behind us. At this point my main concern is the fact that it's going to be rushed. Rushed means mistakes, things overlooked and timeline getting shifted like with 5.6. The overall picture (maybe i'm thinking like a RM here). And we have the 0.4 version still being made, so it means it will be out for discussion probably next week. Or may not. No, it's not being made. See the first post to this thread. Anthony I read the mails and my feeling is that something is brewing between Sara, Zeev and Francois. At least that's my impression, that people are working and they will have something to show. I never saw a direct we are dropping it, just a vague it's essentially dead addressed directly to me by Francois and after that he started to be even more active. So, all indications, something's happening :)
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Zeev, Then that's great! But let's find that out by voting rather than guessing, and rather than politicking. Let's let two competing proposals go head to head. I'd rather find out by first discussing the alternative, rather than just moving ahead to a revote - especially a revote that was placed on a shortened timeline - given the importance of this RFC. But as you clearly disagree, it's your call to make and I respect that. With all due respect, we've been discussing this for literally 5 years since Ilia's commit into 5.4 was reverted: http://marc.info/?l=php-internalsm=127454069030304w=2 I've personally gone through several iterations of it including associated discussion. For this proposal (v0.5), I think the time for fundamental behavior discussion is over. Some disagree, sure. But we've never required 100% consensus before, why start now? I am asking for discussion on the finer points. And indeed some minor modifications have been made. And I'm open to making them. Hence why I specifically asked in the announcement on list that if people disagree they should explain why (**from a technical level**). I personally don't see how a new proposal can fit better than this one, hence why I am moving forward with it. Show me, in writing, in an RFC, how your proposal is better, and I'll gladly withdraw (or delay) this proposal. But short of that, I don't think it's fair to say first discussing the alternative. This topic has been discussed to death in circles over the past several years. You're involved now. Awesome. Show me why your proposal is better rather than trying to just tell me to stop or pause. Show the result of the discussion. Thanks Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On Thu, Feb 19, 2015 at 10:02 AM, Lester Caine les...@lsces.co.uk wrote: While typing this I did think to just scrap what I was writing, but I think it is relevant if only if someone can explain why I am wrong? On 19/02/15 17:06, Anthony Ferrara wrote: With strictly typed $a and $b, the expression drops to 1 possible permutation. And you can detect if it's a valid one. And many static analysis engines do this. I didn't see any proposal that proposes strictly types variables. As for parameters, both strict and coercive typing provide knowledge about the types of parameter inside the function they are defined in, so no advantage to strict typing here. It's not about how data gets in, it's about how data moves once it's in. It's about knowing how types change and flow into other functions that's important. Because that lets you determine more data about the stable (non-error) state of the application. With much of this it is what validation needs doing where. Data coming into the process can either be well constrained, or totally random. Pulling stuff back from a database, This is not the point of this discussion. What you referto has to be done for anything PHP uses, every library, every extension or services (http 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] Digit separators for numeric literals
Nikita Nefedov wrote: 2015-02-19 6:44 GMT+04:00 Rasmus Lerdorf ras...@lerdorf.com: I think it will be difficult to find a separator character that doesn't make a mess of the grammar. Why not space? It's certainly possible (I just checked) and it would look clear I guess: my_func(1 999 999); By the same reasoning spaces could be allowed for identifiers as well, e.g. my func(1 999 999); Too confusing and error prone, IMHO. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC Announce] Generator Return Expressions
Hi folks :) I know everyone is already quite busy attempting to resolve scalar types, assertions, etc. So let me add another RFC to your pre-feature-freeze cognitive overload! This proposal allows the specification of and access to Generator return expressions: https://wiki.php.net/rfc/generator-return-expressions The proposed functionality allows for more robust coroutine multitasking and lays the groundwork for the future implementation of the `yield from` sub-generator syntax found in other languages. Please take a few minutes in the coming days to read the proposal and ask any questions you may have as I plan to initiate a vote for inclusion in PHP 7 as soon as the required discussion period elapses. Thanks for your time and thanks to Nikita for writing the patch to make this happen. - Daniel
[PHP-DEV] [RFC] Comparable: the revenge
Hi all, Those of you with long memories will remember that I proposed a Comparable interface way back in the pre-5.4 days, but withdrew it when it became obvious that there was no consensus for it as a feature and that a vote was likely to fail. RFC: https://wiki.php.net/rfc/comparable PR: https://github.com/php/php-src/pull/1097 Why reanimate it now, I hear you ask? I think that comparisons have only become more prominent in the language: we now have a spaceship operator for explicit comparisons, yet the behaviour of object comparisons can be obscure, to say the least, and the user has no control over how their objects are compared. At this stage, I intend to put this up for a vote on March 5 (vote ending March 12), with the obvious endgame being that this would be included in 7.0. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
On Thu, Feb 19, 2015 at 11:26 PM, Anthony Ferrara ircmax...@gmail.com wrote: Nikita (and all), * Subclassing: Should there be more specific subclasses of EngineException for particular errors? I think there's an important case to be made here. I don't think every error belongs having its own subclass, but there are at least a few cases where it may make sense. This list is based off the current PR (1095) and should be seen as incomplete : 1. Argument Mismatch (not passing required parameter, passing invalid parameter, etc) 2. Parse Error (eval, etc) - note this appears to be implemented already 3. Methods On Non-Objects (call to a member function on null) 4. Call to undefined method (this should be a separate exception from ^^^) I also think it *may* be worth while splitting out Class not found and function not found exceptions into their own type, but not 100% sure. Of course, we can add few subclasses of EngineException. Thanks. Dmitry, Thanks Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Comparable: the revenge
Those of you with long memories will remember that I proposed a
Comparable interface way back in the pre-5.4 days, but withdrew it
when it became obvious that there was no consensus for it as a feature
and that a vote was likely to fail.
RFC: https://wiki.php.net/rfc/comparable
PR: https://github.com/php/php-src/pull/1097
Why reanimate it now, I hear you ask? I think that comparisons have
only become more prominent in the language: we now have a spaceship
operator for explicit comparisons, yet the behaviour of object
comparisons can be obscure, to say the least, and the user has no
control over how their objects are compared.
At this stage, I intend to put this up for a vote on March 5 (vote
ending March 12), with the obvious endgame being that this would be
included in 7.0.
If the responsibility of comparing two objects is pushed into the
objects themselves then the ability to use different comparison
criteria for the same two objects when placing them in two different
structures is taken away. This is actually a very common problem I
have seen people complain about in Java.
Another issue: it allows comparing an object to non-objects (even
though the stated goal is only to compare two objects of the same
type):
class MyClass implements Comparable {
private $val = 0;
function compareTo($a) {
return $this-val = $a;
}
}
$int = 10;
$myClass = new MyClass();
$myClass = $int; // works
$int = $myClass; // if this doesn't produce a warning it at least
doesn't behave the same as the line above it
Ultimately, when comparing two objects it is usually as part of some
algorithm, so instead the Comparator interface could be used:
interface Comparator {
function compare($a, $b): int;
}
But even here I would rather just take a function instead of requiring
it to be the instance of some interface:
function sort($input, callable $comparator($a, $b): int) {
/* … */
}
All in all, I don't think the fundamental idea of the RFC is good. The
Comparable interface is inferior to many other techniques of achieving
the same goal of comparing two objects.
I do want to thank you for taking the time to cite arguments, prior
history and an alternative in the RFC. You have done a pretty good job
on the RFC itself, in my opinion.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Comparable: the revenge
I don't want to get into a lengthy debate (you have your opinion; I
have mine!), but to rebut a couple of specific points:
On 19 February 2015 at 14:19, Levi Morrison le...@php.net wrote:
Another issue: it allows comparing an object to non-objects (even
though the stated goal is only to compare two objects of the same
type):
This is intentional. The wording in the introduction is probably a
little too specific to the object case — I'll fix that.
class MyClass implements Comparable {
private $val = 0;
function compareTo($a) {
return $this-val = $a;
}
}
$int = 10;
$myClass = new MyClass();
$myClass = $int; // works
$int = $myClass; // if this doesn't produce a warning it at least
doesn't behave the same as the line above it
It does behave the same as the line above (with the result inverted,
obviously) — MyClass::compareTo() is still called in this case. The
only time ordering matters is if two objects are being compared, in
which case the leftmost one is the one that has its compareTo() method
called.
But even here I would rather just take a function instead of requiring
it to be the instance of some interface:
function sort($input, callable $comparator($a, $b): int) {
/* … */
}
Fair, but the sorting case isn't the only one that matters,
particularly with = now as part of the language.
I do want to thank you for taking the time to cite arguments, prior
history and an alternative in the RFC. You have done a pretty good job
on the RFC itself, in my opinion.
Thanks. :)
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Comparable: the revenge
But even here I would rather just take a function instead of requiring
it to be the instance of some interface:
function sort($input, callable $comparator($a, $b): int) {
/* … */
}
Fair, but the sorting case isn't the only one that matters,
particularly with = now as part of the language.
For completeness: I advocate accepting a comparator in every case
where custom comparison logic is needed, not just for sorting.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 02/19/2015 04:13 AM, Zeev Suraski wrote: -Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Thursday, February 19, 2015 9:00 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] Reviving scalar type hints On 02/17/2015 01:30 PM, Zeev Suraski wrote: Yes, I already know that. At this point, if I could rephrase the camps a bit I see two different sets of priorities: 1) PHP should do what seems obviously safe to do, to make life easiest for developers. That is, it's patently obvious that 32 and 32 are equivalent, so don't make developers worry about the distinction because to them there isn't one. This is an entirely reasonable position. 2) PHP would benefit hugely from static analysis tools and compile-time type-based optimizations, but those are only possible with code that is strongly typed. Currently such tools do not really exist, but with compile- time-knowlable information could be written and even incorporated into future versions of PHP without API breaks. (I think Anthony demonstrated earlier examples of function calls no longer being slow, for instance, if the type juggling could be removed at compile time.) This is an entirely reasonable position. Larry, There's actually very little difference between coercive type hinting and strict type hinting in terms of performance. If you read what both Dmitry and Anthony said, it should be clear that the vast majority of gains can be had even without any sort of type hinting at all - and as Stas pointed out, JavaScript has some mind blowing JIT optimizations without any explicit type info at all. Moreover, I think it's easy to lose the forest from the trees here, by focusing on a very narrow piece of code - without looking at the bigger picture. Ultimately, if you have a piece of data that you want to pass from a caller to a callee, it could be under one of three labels: 1. A piece of data the callee can use as-is. 2. A piece of data the callee can use after conversion (be it explicit or implicit). 3. A piece of data the callee cannot/shouldn't use. When comparing strict and coercive type hints, there's no difference between them in terms of #1; There's a subtle difference with #3 - but only in the error situation. In other words, for coercive type hints, it would just take a bit more time before they fail, because they have to conduct a few more checks. However, that's an error situation anyway, which is either already going to bail out, or go through error handling code - which would be very slow anyway. So focusing on #2, in a practical real world situation - the difference is actually a lot more subtle than people might think if they only zoom into on the area around parameter passing. The bigger picture is, what would the code author - the one making the call - want to do, semantically? In other words, if you have 32 coming from a database or whatnot, are you likely to want an API that accepts an int to be able to use that? I think the answer is almost always yes. So practically, what will happen with strict typing is that you'd explicitly cast it to int, while with coercive typing - you'd rely on the language to do it for you. Arguably, very little difference between the two in terms of performance. Note that it's possible people will be able to come up with various edge cases where strict typing might somehow alert you to a situation that may push you to change your code in a way it might end up being slightly faster. But those will be edge cases and should be taken in the context - in the vast majority of code patterns, there's zero difference between the two approaches in terms of performance. In terms of functionality, however, there's actually a substantial difference between the two - explicit casting is a lot more aggressive than the coercion rules we're thinking about for coercive type hints. It'll happily and silently coerce Apple into 0, 100 dogs into 100, and 3.1415 into 3. Now, diving back to future potential AOT/JIT, it's simply not true that there's any gain at all from strict typing - or at least, neither Dmitry (who wrote a full JIT compiler for PHP that runs Mandelbrot as fast as gcc does) nor me were able to understand them. Anthony spoke about being able to completely eliminate the zval container and all associated checks, so that in certain situations you'd be able to map a PHP integer all the way down to a C (or asm) integer. That can certainly be done, but it has nothing to do with strict vs. coercive type hints. Here's why: 1. At this point I think it's clear to everyone that inside the called function, there's zero difference between strict and coercive typing (or even the weak typing we were talking about earlier). They're 100% guaranteed to receive what they asked, either because values were coerced or blocked from even making it into the function. 2. On the outside calling code - if you can conduct the level of type inference that would enable you
RE: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
Hi Levi, Just my opinion : Add 'resource', 'object', 'scalar', 'mixed', 'numeric' Remove 'double' (avoid this alias if we decide to encourage 'float' everywhere) Not sure we'll use Boolean and integer but reserve also. Hope 'null', 'true', and 'false' can technically be used as type hints. If not, bad news, especially for null. Love 'int|false' as return type ! Regards François -Message d'origine- De : morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] De la part de Levi Morrison Envoyé : vendredi 20 février 2015 02:36 À : internals Objet : [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7 Sorry: Apparently hit some hotkey for send. On Thu, Feb 19, 2015 at 6:35 PM, Levi Morrison le...@php.net wrote: Dear Internals, I would like to discuss a small RFC for reserving more types in PHP 7: https://wiki.php.net/rfc/reserve_more_types_in_php_7 Essentially it proposes to reserve: int, integer bool, boolean true, false float, double string null It does not make them keywords; it only prevents them from being used in class, interface, trait and namespace names. -- 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: [RFC] Reserving More Types in PHP 7
On Thu, Feb 19, 2015 at 5:36 PM, Levi Morrison le...@php.net wrote: I would like to discuss a small RFC for reserving more types in PHP 7: https://wiki.php.net/rfc/reserve_more_types_in_php_7 Essentially it proposes to reserve: int, integer bool, boolean true, false float, double string null +1 -- I was planning to put this up today and got waylaid. On Thu, Feb 19, 2015 at 8:01 PM, François Laupretre franc...@php.net wrote: Add 'resource', 'object', 'scalar', 'mixed', 'numeric' Remove 'double' (avoid this alias if we decide to encourage 'float' everywhere) Hope 'null', 'true', and 'false' can technically be used as type hints. If not, bad news, especially for null. Love 'int|false' as return type ! If I were to change one thing, it'd be to add some metatypes (possibly as a separate vote): I also agree with everything François said. Reserve these additional types (possibly in a separate vote, up to you). -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
2015-02-12 20:55 GMT-03:00 Stelian Mocanita steli...@php.net: I could compromise to send pull requests and update some of these tools (at least the open source ones) in time for PHP7 release. Print screen taken, will hold you to your words. Please do ;) If the RFC passes I'll be happy to pull request and help to update the static analyzers for PHP7. Other languages are using glob braces syntax and it simply works :) Perhaps you could give it a chance. Many people reply to me saying that they preferred python syntax but after a while they started to like the proposed syntax too, for PHP. Will compile your PR and give it another try with a bit more open mind and see how it goes Thanks for taking the time to read through and explain your angle. You're welcome, Márcio Almada.
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On Thu, Feb 19, 2015 at 6:13 PM, François Laupretre franc...@php.net wrote: De : Pádraic Brady [mailto:padraic.br...@gmail.com] As I understand it, Andrea left her RFC free to be reused, reopened and derived without any specific limitation. It would therefore appear that it would be possible for there to be 100 derived RFCs all owned by different people, i.e. nobody has an exclusive right to either the RFC text or the concept of scalar typehints insofar as I understand it. You're right. The process of taking over an RFC in this case is not defined. Even if Andrea explicitly authorized anyone to derive anything from her work, I thought it was lack of respect for her work to take control and switch to another direction. That's why, while I'm not totally in sync with Anthony's proposal, I think he is acting the right way regarding Andrea's work. I think so too and it is not the 1st time. And yes, apparently, you could have 100 RFCs derived from the same one and published by different people. I also guessed it was forbidden, at least by common sense, but it is possible. I would happily support more rules for such cases. Such as? Competition is good and my past experiences is that in cases like this one, it is nearly an utopia to think that the other party will actually try to reach your needs. So the only way to actually get a RFC representing what you want to do is to have a competitive one. In the other hand, I had other cases where the counter part happily added options and co to have an objective RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.6.6 is available
Hello! The PHP development team announces the immediate availability of PHP 5.6.6. This release fixes several bugs and addresses CVE-2015-0235 and CVE-2015-0273. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.6 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.6.6 Ferenc Kovacs Julien Pauli
Re: [PHP-DEV] [RFC] Comparable: the revenge
On Thu, Feb 19, 2015 at 1:40 PM, Adam Harvey ahar...@php.net wrote: Hi all, Those of you with long memories will remember that I proposed a Comparable interface way back in the pre-5.4 days, but withdrew it when it became obvious that there was no consensus for it as a feature and that a vote was likely to fail. RFC: https://wiki.php.net/rfc/comparable PR: https://github.com/php/php-src/pull/1097 Why reanimate it now, I hear you ask? I think that comparisons have only become more prominent in the language: we now have a spaceship operator for explicit comparisons, yet the behaviour of object comparisons can be obscure, to say the least, and the user has no control over how their objects are compared. At this stage, I intend to put this up for a vote on March 5 (vote ending March 12), with the obvious endgame being that this would be included in 7.0. Thanks, Thanks you :) I like it. It is simple and straightforward. I agree with other that it is easily done using a simple function (Adam's) but I do not like it much, less clear. 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] Using Other Channels (was Scalar Type Declarations v0.5)
De : Pierre Joye [mailto:pierre@gmail.com] Such as? Competition is good and my past experiences is that in cases like this one, it is nearly an utopia to think that the other party will actually try to reach your needs. So the only way to actually get a RFC representing what you want to do is to have a competitive one. Competition is good but needs rules. I am still skeptic about whether bringing concurrent RFCs in such complex and hot subjects does more good than bad. If discussion were meaningful and focused, maybe, but I'm afraid it could degenerate in FUD campaigns, which would waste energy for nothing. You probably don't remember, I experienced such FUD when I proposed a concurrent to phar. That's something I'll try to avoid because it showed that competition with no rule is not the solution. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Nightmares on type hints, annotations, and aop...
Bishop,
Pardon me for saying so, but I don't think you're on to a huge scoop here.
Scalar type hints - of all the kinds we've been talking about here, be them
strict, weak or coercive - can be easily emulated with a couple of lines of
code, we all know that. It's been known for years that strict hints are
is_*() else error equivalent, that weak hints are (mostly) just casts, etc.
Saying the class type hints can be emulated with is_a() calls wouldn't shock
anybody either.
However, the conclusion you seem to draw from that, few language designers
would agree with. Adding first-class, reflectable, analyzable syntax - is
worlds apart from the situation today - regardless of what type of scalar
hinting we talk about. Once we introduce language-level syntax for this
pattern, usage will *explode* compared to what it is today. Explode, not
increase. Tools would be updated to support (and take advantage) of this
new data - in a way they can't practically do with userland 'emulation' of
this behavior. Best practices will be updated. Doc formats will be
changed. Etc etc.
Last, note that you only focused on userland functions. Things are a bit
different with internal functions. The different proposals on the table all
propose to change - in one way or another - the way internal functions
behave. This is much less intuitive to emulate using userland code, for
obvious reasons.
So no, I don't think we're making a bigger deal out of it than it is.
Scalar type hints are a huge deal, and the fact you can emulate them in
userland code today doesn't change that in any way.
Thanks,
Zeev
-Original Message-
From: bishop.bett...@gmail.com [mailto:bishop.bett...@gmail.com] On
Behalf Of Bishop Bettini
Sent: Wednesday, February 18, 2015 2:18 PM
To: PHP internals
Subject: [PHP-DEV] Nightmares on type hints, annotations, and aop...
After a spate of literal coding nightmares, I woke needing to commit these
thoughts to the list. These may have been raised before, I can't
remember,
these debate has been raging for so long.
THING 1: Hints are just is_* wrappers
function f(scalar $s, int $i) { }
effectively is sugar for:
function f($s, $i) {
if (! is_scalar($s)) throw new \InvalidArgumentException();
if (! is_int($i)) throw new \InvalidArgumentException(); }
THING 2: Hints are truthy callables
function my_mixed($m) {
return (null === $m || is_string($m)); } function f(is_scalar $s,
is_int $i,
my_mixed $m) {};
THING 3: Pre- and post- blocks to define contracts, establish formal join
points, with or without hints from above
function f($s, $i, $m)
before {
if (! is_scalar($s)) throw new \InvalidArgumentException; }, inside {
$fp = fopen($s, 'r');
return [ $i, $m ];
},
after ($retval) {
assert(is_array($retval) 2 === count($retval)); }, finally
($retval) {
fclose($fp);
if ($retval instanceof \Exception) {
// I got here by an unhandled exception
}
}
weave('before', 'f', function ($s, $i, $m) {
syslog(LOG_DEBUG, __POINTCUT__); // is 'f'
}
I had to get these off my chest. Forgive me their implementation
ignorance.
I am yet tired and uncaffeinated. To the void I commit their bodies...
bishop
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com wrote: Larry, Anthony, can you expand here at all about the practical benefits of strong-typing for variable passing for the compiler? That seems to be the main point of contention: Whether or not there are real, practical benefits to be had in the compiler of knowing that a call will be in strict mode. (If there are, then the split-mode makes sense If there are not, then there's little benefit to it.) For the normal compiler engine there will be no benefit for the foreseeable future. For a tracing JIT compiler, there will be no advantage. For a local JIT compiler, there can be some optimizations around reduced conversion logic generated (and hence potentially better cache efficiency, etc). A guard would still be generated, but that's a single branch rather than the full cast logic. This would likely be a small gain (likely less than 1%, possibly significantly less). For a AOT compiler (optimizing compiler), more optimizations and therefore gains can be had. The big difference here is that type assertions can be done at compile time. AOT compiler that know type of passed argument and expected parameter type, may eliminate guard check independently on hint semantic (strong or week). If you don't know first or second you'll have to generate guard code anyway independently from hint semantic (strong or week). Is this wrong? We may introduce strong type hints because of your mistake. So that means one less branch (no guard) per argument per function call. In addition, native calls can be used in a lot of cases, which means the compiled code doesn't even need to know about a zval (significant memory and access reduction). This has potential to be significant. Not to mention the other optimizations that are possible. This already worked for as without type hinting. However, I think making this decision based on performance is the incorrect way of doing it. For the Zend engine, there will be no discernible difference between the proposals. It's a red herring. The difference I would focus on is the ability to statically analyze the code (with the benefits that comes with). Completely agree, changing language for compiler is not fair. It's clear that statically typed languages are more suitable but we won't make PHP statically typed. Also, modern JS engines showed - what they may do without typing. In my opinion strict type hints may be useful for program verification, but again, I wouldn't like to change the whole language semantic just to get few unit tests out of the box. Thanks. Dmitry. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC][DISCUSSION] Context Sensitive lexer
Hi internals, I'd like to put the Context Sensitive Lexer RFC into discussion phase: RFC: https://wiki.php.net/rfc/context_sensitive_lexer TL;DR commit: https://github.com/marcioAlmada/php-src/commit/c01014f9 PR: https://github.com/php/php-src/pull/1054 PHP currently has ~64 globally reserved words. Not infrequently, these reserved words end up clashing with legit alternatives to userland API declarations. This RFC proposes minimal changes to have a context sensitive lexer with support for semi-reserved words on PHP7 without causing maintenance issues. This could be especially useful to: - Reduce the surface of BC breaks whenever new keywords are introduced - Avoid restricting userland APIs. Dispensing the need for hacks like unecessary magic method calls or prefixed identifiers. The patch is 98% finished, the entire test suite is passing. I'm still adding more tests to it but the hard part is done. So it's time to discuss! Sincerely, Márcio Almada
Re: [PHP-DEV] PHP 5.6.6 is available
Hi Ferenc, Ferenc Kovacs tyr...@php.net writes: Hello! The PHP development team announces the immediate availability of PHP 5.6.6. This release fixes several bugs and addresses CVE-2015-0235 and CVE-2015-0273. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.6 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.6.6 Taken from the changelog: Removed support for multi-line headers, as the are deprecated by RFC 7230. Isn't this a BC break? Ferenc Kovacs Julien Pauli Cheers, -- Florian Margaine signature.asc Description: PGP signature
Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
2015-02-20 2:36 GMT+01:00 Levi Morrison le...@php.net: int, integer bool, boolean true, false float, double I guess we should add 'real' here as well, since we still have the (real) type cast and is_() type check for consistency: C:\dev\php-srcphp -r var_dump((real) 42, is_real(13.37)); float(42) bool(true) string null -- 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] Nightmares on type hints, annotations, and aop...
Hi Bishop,
On Wed, Feb 18, 2015 at 9:18 PM, Bishop Bettini bis...@php.net wrote:
THING 2: Hints are truthy callables
function my_mixed($m) {
return (null === $m || is_string($m));
}
function f(is_scalar $s, is_int $i, my_mixed $m) {};
This is interesting idea. I'm sure it will be much slower than type hints
as it
calls functions, but it's still interesting idea. i.e. Cost of calling
functions are
not cheap. Inline optimization will help, but it increases byte code size.
Type hint implementation is a lot simpler than this.
THING 3: Pre- and post- blocks to define contracts, establish formal join
points, with or without hints from above
function f($s, $i, $m)
before {
if (! is_scalar($s)) throw new \InvalidArgumentException;
},
inside {
$fp = fopen($s, 'r');
return [ $i, $m ];
},
after ($retval) {
assert(is_array($retval) 2 === count($retval));
},
finally ($retval) {
fclose($fp);
if ($retval instanceof \Exception) {
// I got here by an unhandled exception
}
}
weave('before', 'f', function ($s, $i, $m) {
syslog(LOG_DEBUG, __POINTCUT__); // is 'f'
}
Although it has similarities, AOP and DbC cannot share blocks/etc. AOP is
for production codes, DbC is _not_ for production codes, but only for
development
and testing. These are 2 distinct features.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
Hi all, On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com wrote: I think that naming the new parent exception something like Throwable or Catchable (as Nikita previously suggested) would be a bit more concise in meaning than BaseException. You may not have even meant that name as a formal proposal, but I figured I'd weigh in regardless. :P I think they probably should use namespace... Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
I'm not sure. Currently we don't use namespaces for core classes, but I won't object to change this. Nikita, what do you think? Thanks. Dmitry. On Fri, Feb 20, 2015 at 10:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com wrote: I think that naming the new parent exception something like Throwable or Catchable (as Nikita previously suggested) would be a bit more concise in meaning than BaseException. You may not have even meant that name as a formal proposal, but I figured I'd weigh in regardless. :P I think they probably should use namespace... Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] [RFC] Reserving More Types in PHP 7
Dear Internals, I would like to discuss a small RFC for reserving more types in PHP 7: https://wiki.php.net/rfc/reserve_more_types_in_php_7 Essentially it proposes to reserve: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
Sorry: Apparently hit some hotkey for send. On Thu, Feb 19, 2015 at 6:35 PM, Levi Morrison le...@php.net wrote: Dear Internals, I would like to discuss a small RFC for reserving more types in PHP 7: https://wiki.php.net/rfc/reserve_more_types_in_php_7 Essentially it proposes to reserve: int, integer bool, boolean true, false float, double string null It does not make them keywords; it only prevents them from being used in class, interface, trait and namespace names. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Stas, On Thu, Feb 19, 2015 at 9:32 AM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! So rather than go for the 70-75% consensus that we **know** we have, How we magically know that? We have the (unfinished) vote, which has a tiny bit over 66% for the proposal. Where 75% comes from? Based on the no reasons that people presented, and some back-of-envelope math. Basically, it seemed like there were three reasons people voted no: 1. They don't like strict (Zeev, etc) 2. They don't like weak (Sebastian, etc) 3. They don't like declare() + int-float issue (Levi, Daniel, etc) My view was it seemed to be approximately an even split. So if we assume that, then 33% of the no-voters (approximately) would vote yes for 0.5 since declare is fixed. 66% + (34% * 33%) == 77% I rounded down (saying 70-75). And considering that I've talked to at least 5 people who've said that they would explicitly change from no to yes for the proposed v0.5, that would be 71%. Sure, some people may change yes to no. And people may not vote this time who voted last time. The only way to know for sure is a vote. Which is why I'm bringing it to a vote. I wouldn't be doing this if I didn't think it would pass. Saying a problem doesn't exist doesn't make it go away. Except if it really doesn't exist, so there's nothing to go away :) Saying static analysis a hundred times doesn't magically makes it a strong argument when nobody showed that it's impossible or even much harder without it (many _claimed_ that, but I so far have seen very little substantiation for these claims). As someone who's built a static analyzer for PHP, I can say that it is much harder without strict typing. The reason is, with strict typing you only need to deal with 8 possible states for every variable (int, float, bool, resource, array, object, callable, null and string). And many of those states you can eliminate based on context (you know an argument passed to an int declared parameter will always be an int). Without strict typing, you also need to consider virtual states: castable object (internally implementing get()), stringable object (implementing __tostring), numeric string (123), kind-of numeric string (123 abc), etc. And many of those states *can't* be eliminated based on context. So if a static analysis engine models an application as a graph of potential state changes, the number of edges goes up exponentially when you can't eliminate possible variable states. So a lot of work goes into inferring the possible states involved. An example is that ($a + $b) we know can never produce a string. We know it can never produce a bool, resource, array, callable or null. The only things it can produce is an object, an int or a float. So if we see expressions of the form `$c = ($a + $b)`, we can immediately deduce something about $c and therefore reduce the number of possible states. With strict typing, if we then pass $c to a function expecting int, we know that C must be an int. Which means that $a and $b therefore **must** be castable to an integer (otherwise an error will be thrown down the road). So we've just reduced $a down to 5 types: int, numeric string, null, bool and castable object (from at least 12). And $b the same. So our expression has 10 possible valid (non-error-case) permutations. Down from the approximately 432 possibilities before hand (12 for $a, 12 for $b, 3 for $c). And that's with unknown $a and unknown $b. The only static analysis engine I've come across that does this for dynamic types is Klee (LLVM project). With strictly typed $a and $b, the expression drops to 1 possible permutation. And you can detect if it's a valid one. And many static analysis engines do this. It's not that static analysis is impossible without strict typing. It's that it gets drastically easier. Both in terms of processing power, and in terms of edge-cases that you need to support. Does that substantiate the claim? If not, I'm definitely open to discussing it further. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Hey Anthony,
-Ursprüngliche Nachricht-
Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
Gesendet: Mittwoch, 18. Februar 2015 21:45
An: internals@lists.php.net
Betreff: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Dear Internals,
Since the resignation of Andrea, the mixed-mode type hint (called declaration
in the proposal) proposal has been left
abandoned.
Considering that the ending votes were 67/34 (66.3%) with several no-votes
being only due to reasonably minor issues with
the proposal, I would like to re-propose her RFC with three minor
modifications:
1. declare(strict_types=1) (if used) is required to be the first instruction
in the file only. No other usages allowed.
2. declare(strict_types=1) {} (block mode) is specifically disallowed.
3. int typed variables can resolve a parameter type of float So calling
requiresAFloat(10) will work even in strict mode.
As this topic has and is being discussed to death, I have put a very large
discussion points section:
https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points
I would kindly ask, before replying that you check to see if your question is
answered in that list.
If it is not, please follow up here and I will update the RFC.
If your question is listed and you feel that it wasn't given proper due,
please let's discuss that.
https://wiki.php.net/rfc/scalar_type_hints_v5
Considering this proposal is a minor tweak on an already-discussed and
voted-on proposal, I plan on bringing this RFC to
vote 1 week from today (on February 25th, 2015).
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php
I have some questions:
you wrote: aliases are removed (integer and boolean)
what about the aliases real and double?
You wrote: behaviour of weak type checks: float - int *Only non-NaN floats
between PHP_INT_MIN and PHP_INT_MAX accepted. (New in PHP 7, see the ZPP
Failure on Overflow RFC)
What about INF? Can INF be passed or not and if so, how is it converted?
Personally I would be stricter and disallow int-bool, float-bool,
string-bool as well as bool - int, bool - float and bool - string (at least
for this RFC)
Why?
1. I already mentioned the common if(strpos(..)){} case but is something which
none of the RFC addressed so far and probably goes too far (you wrote In
addition to userland functions, the strict type checking mode also affects
extension and built-in PHP functions: but control structures are not affected,
right?)
2. It supports an inconsistency in PHP which we should try to get away with
rather than promoting it. Following an example:
function foo(string $x){
var_dump($x);
bar($x);
}
function bar(bool $x){
var_dump($x);
baz($x);
}
function baz(string $x){
var_dump($x);}
foo(0);
and the output would be:
string(1) 0
bool(false)
string(0)
Sure, removing the implicit conversions from and to bool do not pretend that
the same would happen if one uses manual conversions instead. Yet, IMO we
should forbid the implicit conversion from and to bool now and add it later on
with consistent conversion rules. This way we have more time to think about a
clean solution and adding implicit conversion from and to bool should also not
be a BC break in 7.1
Another example:
function foo(int $x){
var_dump($x);
bar($x);
}
function bar(string $x){
var_dump($x);
}
foo(false);
bar(false);
and output:
int(0)
string(1) 0
string(0)
I think you get the inconsistency I am writing about.
About widening. It is not clear from the RFC if widening is only applied for
int - float or also for bool - int, bool - float respectively.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On Thu, Feb 19, 2015 at 8:21 AM, Lester Caine les...@lsces.co.uk wrote: On 19/02/15 12:52, Zeev Suraski wrote: Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? I think the guiding principal for these conversions should be no data loss. This may mean we have different limits on different architectures, depending on whether they're 32-bit or 64-bit. This still leaves the 'black hole' caused by the fact that databases are actively using 'BIGINT' even on 32 bit platforms. It may be that the only practical approach is gmp, but using that and writing code that selects that on a 32bit platform, then switching to clean 64bit maths on a 64bit platform does not sound like simplifying things? As with other debates, some say ignore 32 bit, and others say lets loose the constraints altogether, but having a fundamental type behave differently depending on platform is a problem? Lester, You keep coming with this topic in every possible threads. As I understand that DB interactions are some of the primary usages of PHP, this discussion has nothing to do with that. DB drivers will do what they have to do to deal with PHP DB types, as they always do. It would be very good if you could focus on the actual content of a RFC or discussion instead. -- 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: [RFC] Exceptions in the engine
On Thu, Feb 19, 2015 at 7:06 PM, Dan Ackroyd dan...@basereality.com wrote: On 19 February 2015 at 15:46, Dmitry Stogov dmi...@zend.com wrote: Exception declares protected properties that may be used in child classes directly. This is not possible with interface. So, you're saying it's easier to implement? That isn't a fantastic way of making a language design decision. We don't design from scratch. We improve PHP for years, and we are tying to do it with minimal breaks for our users. If we may keep compatibility, we would prefer to keep it, instead of allying yet another pattern from a modern book. Dmitry. cheers Dan
Re: [PHP-DEV] [RFC] Exceptions in the engine
I am not familiar with the implementation details but from my perspective this would be a nice improvement. I have had a difficult time debugging PHP fatal errors over the years and I think this kind of change would help improve that. On Mon, Oct 6, 2014 at 4:53 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Thanks, Nikita [1]: https://wiki.php.net/rfc/engine_exceptions -- Connect with me on *http://twitter.com/jwage* http://twitter.com/jwage
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
On 19 February 2015 at 16:25, Dmitry Stogov dmi...@zend.com wrote: we are tying to do it with minimal breaks for our users. If we may keep compatibility, we would prefer to keep it, Yeah - you still haven't said why choosing to extend exception rather than using an interface has fewer BC problems. We thought about Throwable or Catchable interface, but this change would require more changes and will make more BC breaks. Exception declares protected properties that may be used in child classes directly. Any class that extends Exception currently will still behave as it does before. The only change to the Exception class would be add the interface to it's declaration. I can't see how this causes a BC break. Please can you say what the BC break is if you think there is one. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
On 19 February 2015 at 15:46, Dmitry Stogov dmi...@zend.com wrote: Exception declares protected properties that may be used in child classes directly. This is not possible with interface. So, you're saying it's easier to implement? That isn't a fantastic way of making a language design decision. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On 19/02/15 15:21, Zeev Suraski wrote: Focusing on my email to Sara (and several others), there is NOTHING, nothing wrong with a bit of private communications trying to gauge support, opposition, gaps and sort out differences before going for a public discussion. My original comment was on the basis that we have had too much 'we agreed on list X' and I think a lot of the underlying discussion while voluminous here has lost some of the critical fine detail ... because it has not been copied here. Currently 0.4 and 0.5 versions are still being discussed, but neither relax the weak/strict debate which is apparently so essential in other forums? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
On Thu, Feb 19, 2015 at 7:45 AM, Pierre Joye pierre@gmail.com wrote: On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov dmi...@zend.com wrote: On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org wrote: Morning internals, The expectations RFC is now in voting phase: https://wiki.php.net/rfc/expectations#vote I totally miss the Expectation RFC announcement. Where the RFC was actually proposed for discussions. I have been following up the DbC thread, seeing some mentions but that's it. The RFC itself popped up 3 days ago. It's from 2013 Yes, but and it was discussed actively during last week. Still, no announce for a discussion about this specific RFC. And really, the content of the RFC is almost empty, pointing to the ML archive is really not the right way :) So, back to more useful feedback. I like the concept and idea but still not sure about the custom exception vs AssertException. My gut feeling tells me that it could be better to solve that prior this vote, which actually asks to choose something we did not define yet. It could be in the same RFC (and making it more complete while being at it). -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reviving scalar type hints
On 19/02/15 12:52, Zeev Suraski wrote: Now that all made sense! My only grey area is 'allowing sensible ones' where the size is an integral part of what is 'sensible' ... the one where conventional strict typing uses a type of the right size? I think the guiding principal for these conversions should be no data loss. This may mean we have different limits on different architectures, depending on whether they're 32-bit or 64-bit. This still leaves the 'black hole' caused by the fact that databases are actively using 'BIGINT' even on 32 bit platforms. It may be that the only practical approach is gmp, but using that and writing code that selects that on a 32bit platform, then switching to clean 64bit maths on a 64bit platform does not sound like simplifying things? As with other debates, some say ignore 32 bit, and others say lets loose the constraints altogether, but having a fundamental type behave differently depending on platform is a problem? -- 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] Using Other Channels (was Scalar Type Declarations v0.5)
Arvids, I meant it in a way that no other RFC has failed so many times or had so much misunderstanding or divide. No scalar type proposal has made it through a vote. So none of them have technically failed (all except the current one were withdrawn). Sometimes it is required to ditch the preferences of people and do stuff for the greater good. Right now I see most people (not all) pushing their own agendas not really giving a damn over the big picture, the timeline and the fact that at this moment RFC already too late for 7.0 according to the Release Process RFC - they cannot be discussed and voted before the feature freeze. Yes, it can be pushed rather easily, but it means breaking the release process RFC again. See the pattern here? Well, 0.5, as a minor tweak on 0.3 *could* (by the RFC process) go to vote on the 25th. Which would end on the 11th. A full 4 days before freeze. Without breaking the release process. However, I would be happy to target 7.1 even if the vote passes prior to freeze (assuming an RFC to reserve the scalar type names is proposed and passes, otherwise 8.0). My reason for pushing for the vote is not to get it into 7, but to get it over with. We've been discussing these proposals for years. We have one that came extremely close to passing (save for a few minor issues people voted no to, which are now fixed). Let's get it behind us. And we have the 0.4 version still being made, so it means it will be out for discussion probably next week. Or may not. No, it's not being made. See the first post to this thread. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Hi! Based on the no reasons that people presented, and some back-of-envelope math. That is not knowing, much less **knowing**. That is a guess based on an estimate and set of assumptions, some of which very well may be wrong (such as, people can have more than one reason to vote no). The reason is, with strict typing you only need to deal with 8 possible states for every variable (int, float, bool, resource, array, object, callable, null and string). And many of those states you can eliminate based on context (you know an argument passed to an int declared parameter will always be an int). This is possible with coercive typing too, if the argument is declared int then it will be coerced to int. Without strict typing, you also need to consider virtual states: castable object (internally implementing get()), stringable object (implementing __tostring), numeric string (123), kind-of numeric string (123 abc), etc. And many of those states *can't* be eliminated based on context. I don't see why you don't need to consider them anyway - if your analyzer cares about ability of the object to be casted to a string, you'd have to carry this information anyway - for use in (string), echo, $foo, internal functions, etc. So again no advantage here. An example is that ($a + $b) we know can never produce a string. We know it can never produce a bool, resource, array, callable or null. The only things it can produce is an object, an int or a float. So if we see expressions of the form `$c = ($a + $b)`, we can immediately deduce something about $c and therefore reduce the number of possible states. This is right, but no advantage to strict typing here, this is true under any typing model. With strict typing, if we then pass $c to a function expecting int, we know that C must be an int. Which means that $a and $b therefore That seems to be an incorrect assumption - passing something to function asking for an int doesn't mean it is an int. It means that inside function it would be int or fail happens, but that is achieved with coercive typing too, so no advantage to strict typing here. Of course, since we already know $c is an int or a float or an object, no additional information here is obtained, and we do not know anything about $c itself - we only know the A-B is true but we don't know whether A is true and thus not whether B is true. **must** be castable to an integer (otherwise an error will be thrown down the road). So we've just reduced $a down to 5 types: int, numeric string, null, bool and castable object (from at least 12). And $b the Yes, after the expression is done and *if* it did not error out, we can deduce some things about $a's value *after* the expression. But we have no guarantees the expression would succeed and no advantage to string typing which does not come into play here at all. same. So our expression has 10 possible valid (non-error-case) permutations. Down from the approximately 432 possibilities before hand (12 for $a, 12 for $b, 3 for $c). And that's with unknown $a and unknown $b. Still don't see any advantage to strict typing here. Deduction about the behavior of + can be made without any strict typing involved, as far as I can see. With strictly typed $a and $b, the expression drops to 1 possible permutation. And you can detect if it's a valid one. And many static analysis engines do this. I didn't see any proposal that proposes strictly types variables. As for parameters, both strict and coercive typing provide knowledge about the types of parameter inside the function they are defined in, so no advantage to strict typing here. It's not that static analysis is impossible without strict typing. It's that it gets drastically easier. Both in terms of processing It may be so, but yet again it was not demonstrated. Does that substantiate the claim? If not, I'm definitely open to discussing it further. So far I did not see any substantiation, unless I have not understood what your analyzer is doing. -- 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] Expectations
On 19 February 2015 at 15:45, Pierre Joye pierre@gmail.com wrote: Still, no announce for a discussion about this specific RFC. And really, the content of the RFC is almost empty, pointing to the ML archive is really not the right way :) There was an RFC announce thread 3 days ago. I agree 3 days is a short period of time, but the announce thread existed. Maybe it was a reply to DbC with a changed subject and your mail client didn't show it as new? I don't know, there was definitely a thread though. On 19 February 2015 at 16:06, Pierre Joye pierre@gmail.com wrote: I like the concept and idea but still not sure about the custom exception vs AssertException. Looking at the implementation, it seems that the custom exception still has to descend from AssertException https://github.com/php/php-src/pull/1088/files#diff-232f2dffbb06c0b6004724d8a498e7e7R248 That seems like a good restriction to me. You can still catch everything with AssertException but you can make it more specific if you want. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On Thu, Feb 19, 2015 at 5:24 AM, Anthony Ferrara ircmax...@gmail.com wrote: On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre franc...@php.net wrote: As long as she does not officially gives up (posting to the list), I'll keep considering Sara still has the lead on scalar type hinting. If she officially gives up, I'll immediately propose to take it over and, if we are several to want it, we'll discuss. My official statement: I'm backing away from my 0.4 not-even-a-full-proposal-just-a-testing-of-the-waters because there are at least two other strong proposals on the table and introducing a third won't help the matter, it'll just make things more divided and complicated. I'll focus my effort on influencing those two to make them more sensible from my pov. Ze'ev and François have not-so-politely asked [Sara] to not put 0.4 forward since they have something they believe they have consensus on. That quote was said, but it's not entirely accurate. Ze'ev, as he's protested on this list, was in fact perfectly polite in his correspondence. In fact, he's been leaning on me to co-author his RFC, probably in an attempt to make it balanced, rather than partisan. If he was impolite at all, it was the multiple pestering twitter DMs trying to get me to provide feedback while I was running around on a busy day. :) Please notice the smiley at the end of that last sentence... for the love of god notice it. When I wrote that earlier statement, I was still steaming at François, who *was* quite impolite and a bit bullying in his out-of-band email. I didn't want to make him the single-target subject of any backlash though, so I fuzzed it inti Ze'ev as well. That's my bad. My pulling back at this stage is not a reflection of the tone of his email, I'm way to obstinate to put up with foolishness like that. I'm pulling back for the sake of this community. Three RFCs active on a single topic is too many. If one of these succeeds, great. If not, I can step forward again. That might mean this gets deferred to 7.1, but that's the breaks. So while it may not have been abandoned, it was sandbagged (sabotaged, strong-armed, etc). I used abandoned as a light term to not point out to list what strong-arming happened behind the scenes. But since you apparently don't want other channels used... Strong-arm is an unnecessarily forceful term. I'm setting it on pause pending the other two proposals. The reasons for which include you putting forth 0.5, so if you want to assign blame for pushing mine out of the picture, include yourself. (But don't really, because I'm glad you have a proposal that you're running with). -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Hi!
At the function border, yes. But not beyond that.
Not sure what you mean here. If the value is identified as int, it
remains int. How strict typing would change that?
Sort-of correct. We don't know if A is true, but we know what
conditions need to exist for A-B to be true. We know that A can be
any value. It could be a float. But that would lead to an error down
the road when the sum is passed to the function typing for an int.
Yes, and nothing guarantees you that the error actually does not occur
in this code, so you can't derive any additional information here.
Therefore, by knowing $c is passed to a function expecting an int, we
have information about stable states for $a and $b which would result
in a stable state for $c.
But that is not related to strict typing - this is a property of +,
which does not change with strict typing.
With strict mode, then we can work backwards and see that if $a is set
to 3.5, that we know that it's not a stable state (because at best an
error will be created).
I don't see how you can work backwards. You can, again, reason that if
you passed the function call, then $c was int. But you can not derive
from that that $c was indeed int, since you don't know that the function
call actually worked. In fact, then whole purpose of strict typing is
catering for the case where it didn't, so you can not assume such cases
do not exist and also propose string typing - it is logically inconsistent.
With coercive typing (weak), you can't work backwards there because
3.5 + 1.5 is 5.0 which would be acceptable for an int hint. So you
have a LOT more possibilities to contend with.
You have the same possibilities in any case. Nothing guarantees you that
in fact, in real code, $a and $b is not exactly 3.5 and 1.5. Nothing
prevents them from being so.
This isn't so much about proving an application correct as it is about
proving information about the stable (non-error) states of the
program.
If you just ignore any cases when program may malfunction, what use such
analyzer would be for any real program - which with probability close to
1 has states in which it malfunctions? I still don't see how strict
typing adds any information here.
So with coercive typing (weak), the ability to detect errors and prove
stable states of the application is reduced and requires significantly
more computation.
I still don't see how. You only say that if we assume that the program
never fails, then we can derive more information from strict typing, but
if we could write programs that never fail we didn't have any need in
strict typing at the first place!
In compiled languages, this problem is solved by pre-resolving the types
of *all* variables prior to execution, but it is not possible in PHP, so
I don't see where the reduction comes from.
I'm talking about using the static analyzer to prove properties of the
stable (non-error) state. Yes, at runtime you only know things about
$a after the expression. But at static time, we can prove based on
what we know of $c, the acceptable input states that could possibly
lead to a stable state. Yes, you can generate errors. But the entire
point of static analysis is to detect the possibility of these errors
ahead of time rather than at runtime.
I still don't see how it is a useful thing. You are saying that by
inserting a code in your program somewhere that says if(!is_int($a)) {
exit(0);} you magically improve your knowledge about your program
*before* this code line. This seems to be a baseless claim, and quite
strange - whatever post-conditions you declare, it can not go back in
time and make the code before the post-condition somehow change or make
your knowledge about this code somehow better just because you have
added some code at the end.
But we're talking about much more than the behavior of one operation.
We're talking about the behavior of the entire set of function calls
around it (and the flow of type information based on these predictable
operations). So while + itself has no advantage from strict types,
passing the result to a function expecting an integer does give you a
lot of information about the non-error possibilities that the +
operation can have.
The whole point is that these operations are not predictable. What
you're doing here is saying I don't care about hard cases where program
malfunctions and then define any unexpected input as a hard case. With
this definition, of course, it is very easy to reason about the
remaining cases, only this reasoning is useless since it does not cover
what happens in real program run. That's like saying if you have code
that says $a = $b/$c then you can derive from mere existence of such
code that $c is non-zero, since otherwise the program fails. But of
course you can't derive that $c is non-zero only because you wrote a
code that relies on it! Otherwise no debugging would be ever necessary :)
It's not about how data gets in, it's about how data moves once
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Thursday, February 19, 2015 4:04 PM To: Zeev Suraski Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) Zeev, That was a quote directly from Sara in a public chat room. It wasn't someone else. So it seems like there was a failure in communication if you felt that it was 100% polite, and she described it as not-so-politely. Ouch. I'm really not sure why she felt that way. I'll follow up with her to try and understand. Then that's great! But let's find that out by voting rather than guessing, and rather than politicking. Let's let two competing proposals go head to head. I'd rather find out by first discussing the alternative, rather than just moving ahead to a revote - especially a revote that was placed on a shortened timeline - given the importance of this RFC. But as you clearly disagree, it's your call to make and I respect that. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
Hi! So rather than go for the 70-75% consensus that we **know** we have, How we magically know that? We have the (unfinished) vote, which has a tiny bit over 66% for the proposal. Where 75% comes from? Saying a problem doesn't exist doesn't make it go away. Except if it really doesn't exist, so there's nothing to go away :) Saying static analysis a hundred times doesn't magically makes it a strong argument when nobody showed that it's impossible or even much harder without it (many _claimed_ that, but I so far have seen very little substantiation for these claims). -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Thursday, February 19, 2015 4:24 PM To: Zeev Suraski Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) Zeev, This topic has been discussed to death in circles over the past several years. You're involved now. Awesome. Show me why your proposal is better rather than trying to just tell me to stop or pause. Show the result of the discussion. I already said I respect your decision, even if I disagree with it. Holding absolutely no grudge. The key tenets of the proposal that's being worked on have already been shared on internals. Without putting words in your mouth, based on the feedback you've provided over the last few days I don't have high hopes that you personally would find it better, but I'm hoping many others would. The formal RFC takes a bit more time to phrase, but I hope we'll be able to finish the first version today or tomorrow. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, February 19, 2015 4:09 PM To: Zeev Suraski Cc: Anthony Ferrara; PHP internals Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) We have seen off list discussions or pressures many times in the pasts. I have (other too but I can only talk for myself) been said an insane amount of times to stop private discussions, for anything related to php core. There is no exception to this rule. I repeat: There is NO exception to this rule. I disagree. Completely. I did not expect you to agree. I would be surprised if you do. I think 1:1 or group discussions are completely legitimate, and they're not only legitimate - they can be very productive. There's a huge gap between making decisions in closed groups, or doing 'arm bending' - and private discussions, which I repeat, are completely legitimate. Private discussions happen all the time, in countless mediums. Conferences, emails, IRC (public in theory, private in practice), Twitter DMs and more. There's absolutely nothing wrong with discussing an idea directly with one or more people before bugging thousands of people with it. They'd all be better served if the idea presented to them already had a slightly more than just one person standing behind it (which is an inherent side effect of barring private discussions as you suggest), and had some of the initial issues weeded out. To discuss at an idea or concept at events and co? Indeed. We all do that. The difference is how to move it to a group discussions and grab other people thoughts to actually get it done, with consensus. The latter part is totally absent using your process. Discussing, working, implementing something for weeks or months privately? NDA and all that? Sorry, this is not the PHP I want. Weeding out the initial issues? I wonder which magic you use to be able to figure out all issues based on the experiences or thoughts of a couple of people. It does not work. What you say is that a very small group is able to pin point the perfect proposal better than actually discussing it on the open channels. This is wrong in so many ways. Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
2015-02-19 16:51 GMT+02:00 Pierre Joye pierre@gmail.com: On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, February 19, 2015 4:09 PM To: Zeev Suraski Cc: Anthony Ferrara; PHP internals Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) We have seen off list discussions or pressures many times in the pasts. I have (other too but I can only talk for myself) been said an insane amount of times to stop private discussions, for anything related to php core. There is no exception to this rule. I repeat: There is NO exception to this rule. I disagree. Completely. I did not expect you to agree. I would be surprised if you do. I think 1:1 or group discussions are completely legitimate, and they're not only legitimate - they can be very productive. There's a huge gap between making decisions in closed groups, or doing 'arm bending' - and private discussions, which I repeat, are completely legitimate. Private discussions happen all the time, in countless mediums. Conferences, emails, IRC (public in theory, private in practice), Twitter DMs and more. There's absolutely nothing wrong with discussing an idea directly with one or more people before bugging thousands of people with it. They'd all be better served if the idea presented to them already had a slightly more than just one person standing behind it (which is an inherent side effect of barring private discussions as you suggest), and had some of the initial issues weeded out. To discuss at an idea or concept at events and co? Indeed. We all do that. The difference is how to move it to a group discussions and grab other people thoughts to actually get it done, with consensus. The latter part is totally absent using your process. Discussing, working, implementing something for weeks or months privately? NDA and all that? Sorry, this is not the PHP I want. Weeding out the initial issues? I wonder which magic you use to be able to figure out all issues based on the experiences or thoughts of a couple of people. It does not work. What you say is that a very small group is able to pin point the perfect proposal better than actually discussing it on the open channels. This is wrong in so many ways. Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I think this starts to go the route of putting things into absolute. Ideal things tend not to happen/work in the real world to the letter. Some things just don't work out by themselves. The Type Hinting RFC's are an anomaly in the regular PHP Core workflow and need some creative handling. My personal view is that the RFC requires a mediator - the person. who is more or less impartial to what type of hints get into PHP and is able to handle communications between groups and bring them together. RFC needs a triage. It needs someone to make a game plan and implement it. Not someone developing one or the other proposal, but a strictly managing entity. Because the further we go, the more things are need to be taken care of. I believe the Type Hint project reached the point, where it can't be handled by a single person. It touches into some other RFC's in one or the other way, sometimes maybe requiring some adjustments in the related RFC or the type hints itself. Also, whatever way it goes at this point, the RFC's are not going to make into 7.0 if we follow the release process properly. So, there needs some decision making to happen considering the PHP itself, like reserving keywords for 7.0, doing typehints for 7.1 and stuff alike. Maybe it does not look like I have described it from inside, but from the side it looks like a disaster is brewing and it's gonna blow any second now leading to rushed decisions that may screw up things. I saw similar situations a few times in my carrier and I certainly have that feel right now. I'd give it 50/50 chance that something will go wrong here.
RE: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, February 19, 2015 4:09 PM To: Zeev Suraski Cc: Anthony Ferrara; PHP internals Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5) We have seen off list discussions or pressures many times in the pasts. I have (other too but I can only talk for myself) been said an insane amount of times to stop private discussions, for anything related to php core. There is no exception to this rule. I repeat: There is NO exception to this rule. I disagree. Completely. I think 1:1 or group discussions are completely legitimate, and they're not only legitimate - they can be very productive. There's a huge gap between making decisions in closed groups, or doing 'arm bending' - and private discussions, which I repeat, are completely legitimate. Private discussions happen all the time, in countless mediums. Conferences, emails, IRC (public in theory, private in practice), Twitter DMs and more. There's absolutely nothing wrong with discussing an idea directly with one or more people before bugging thousands of people with it. They'd all be better served if the idea presented to them already had a slightly more than just one person standing behind it (which is an inherent side effect of barring private discussions as you suggest), and had some of the initial issues weeded out. Now, if such ideas are presented as a final dictation with no opportunity to discuss them - that's is in fact problematic, although ultimately, there's always the bar of the vote. Regardless, this isn't the case here. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
