Re: [PHP-DEV] Adding weekdays to DateTime resets the time
I think the best approach would be to open a bug under https://bugs.php.net/
since this does
not look like intended behavior.
Regards,
Stelian
On Mon, May 4, 2015 at 5:33 PM, Markus Fasselt markus.fass...@gmail.com
wrote:
Hi,
when I modify a DateTime object and add or subtract weekdays, it happens
that the current time is reset to 00:00:00.
This effect does not occur when I add days. I also experienced the same
behavior with strototime.
?php
$a = new DateTime(strtotime('2015-05-04 17:22'));
var_dump((string) $a-format('Y-m-d H:i:s')); // 2015-05-04 17:22:00
$a-modify('+1 day');
var_dump((string) $a-format('Y-m-d H:i:s')); // 2015-05-05 17:22:00
$a-modify('+1 weekday');
var_dump((string) $a-format('Y-m-d H:i:s')); 2015-05-06 00:00:00
var_dump(date('Y-m-d H:i:s', strtotime('+1 weekday'))); // 2015-05-05
00:00:00
http://3v4l.org/554H4
There seems to be slighly different behavior between the different PHP
versions. strotime always had this behavior. DateTime::modify() worked
correct until PHP 5.3.5.
I don't know if this behavior was changed on purpose (I didn't find
something on it). If so, why? Otherwise I would suggest to fix this, as
it is really confusing.
Regards,
Markus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PDO Oracle driver
The removal of pdo_oci had been suggested as part of the Removal of dead or not yet PHP7 ported SAPIs and extensions RFC, but there has been feedback from Christopher Jones, that the extension will be supported by Oracle.[1] [1] https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8 Thanks for the info. Having Oracle supporting the extensions would be great, but I still feel like they should be re-released or something when they are done. While the OCI8 ext works with current versions, pdo_oci has been experimental for a long time and never reached maturity. Maybe Christopher Jones can jump in here and shed some light on the matter. Regards, Stelian On Wed, Apr 22, 2015 at 1:13 PM, Christoph Becker cmbecke...@gmx.de wrote: Stelian Mocanita wrote: I would like to ask what on your thoughts on removing the Oracle drive for PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php ) at least since it's been experimental for a long time now, and it has long standing open bugs, such as: https://bugs.php.net/bug.php?id=37706 https://bugs.php.net/bug.php?id=46728 https://bugs.php.net/bug.php?id=60994 I know that the extension is marked as experimental already but based on the current status, it's not even that and a significant amount of basic functionality is broken. The removal of pdo_oci had been suggested as part of the Removal of dead or not yet PHP7 ported SAPIs and extensions RFC, but there has been feedback from Christopher Jones, that the extension will be supported by Oracle.[1] [1] https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8 -- Christoph M. Becker
Re: [PHP-DEV] PDO Oracle driver
Peter, I did not know about the documentation part, thanks for clearing that out. I would like to ask though, what is the benefit of having the dead extensions there? From my point of view, it does more harm than good having them in the manual (I am only referring here to extensions that never got to a production grade). On marking the extension as dead, how would we proceed in this case? Thank you, Stelian On Wed, Apr 22, 2015 at 12:34 PM, Peter Cowburn petercowb...@gmail.com wrote: On 22 April 2015 at 11:24, Peter Cowburn petercowb...@gmail.com wrote: cc-ing doc list On 22 April 2015 at 10:40, Stelian Mocanita stelian.mocan...@gmail.com wrote: Hello internals, I would like to ask what on your thoughts on removing the Oracle drive for PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php ) at least since it's been experimental for a long time now, and it has long standing open bugs, such as: From the documentation point of view: Just because an extension is considered experimental, or indeed unmaintained, is no reason to remove the extension from the manual. We have a bunch of extensions marked as experimental [1] or dead [2] and I don't see why pdo_oci should be any different. https://bugs.php.net/bug.php?id=37706 https://bugs.php.net/bug.php?id=46728 https://bugs.php.net/bug.php?id=60994 I know that the extension is marked as experimental already but based on the current status, it's not even that and a significant amount of basic functionality is broken. Let's mark the extension as dead in the manual, as we do with other dead extensions. Regards, Stelian [1] bcompiler, blenc, dbplus, haru, memtrack, ming, paradox, pdo_4d, pdo_oci, sca, sdodasrel, spl_types, svn, swish, vpopmail, xmlrpc [2] classkit, fam, fdf, iisfunc, msession, nis, session_pgsql
[PHP-DEV] PDO Oracle driver
Hello internals, I would like to ask what on your thoughts on removing the Oracle drive for PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php) at least since it's been experimental for a long time now, and it has long standing open bugs, such as: https://bugs.php.net/bug.php?id=37706 https://bugs.php.net/bug.php?id=46728 https://bugs.php.net/bug.php?id=60994 I know that the extension is marked as experimental already but based on the current status, it's not even that and a significant amount of basic functionality is broken. Regards, Stelian
Re: [PHP-DEV] Vote process change proposal
Why we want to block it? What's wrong in convincing people that your idea is OK (or that it's not OK, for that matter)? Isn't it kind of the whole point of discussing it? While I agree with discussing an ongoing vote, I do not find it ok for people to be able to see the current status of an ongoing vote. This might lead to harassing people into voting just to change the outcome. Clear example: The vote score is 21-7 so I know I need another vote to pass, so I call in an acquaintance or friend to vote my way. All the democratic votes I have in mind are hidden until the vote closes, and here I am referring to any election out there, or even referendum. So now parallel to voting we get threads announcing everybody's votes. Yay, more noise! Or, even worse, given current tendencies, somebody submits a proposal, couple of people say yeah good idea, then vote happens and somehow there's 30 no votes without any explanation - and without possibility to fix it since by the time the proposer knows it the proposal is already declined. It wouldn't be very encouraging to submit RFCs with such process. You misunderstood me or I did not formulate that clear enough. What I meant to say is that there are already people that go in the existing opened voting thread and explain their vote, e.g. I voted no on this because I think that won't work. I was not referring here to each one opening a thread, sorry for explaining it poorly. Stelian On Tue, Mar 17, 2015 at 9:44 PM, johnc...@gmail.com wrote: I see absolutely no issues with the visibility of votes, or the act of “lobbying” for someone’s vote. On Tue, Mar 17, 2015 at 4:36 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! This would block voting lobbying in various social channels based on possible outcomes, and would allow voting to run its course unaltered. The people Why we want to block it? What's wrong in convincing people that your idea is OK (or that it's not OK, for that matter)? Isn't it kind of the whole point of discussing it? want to share their vote option, can still do that in the mailing list where some already justify their votes. So now parallel to voting we get threads announcing everybody's votes. Yay, more noise! Or, even worse, given current tendencies, somebody submits a proposal, couple of people say yeah good idea, then vote happens and somehow there's 30 no votes without any explanation - and without possibility to fix it since by the time the proposer knows it the proposal is already declined. It wouldn't be very encouraging to submit RFCs with such process. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Vote process change proposal
Hello internals, In the light of recent events, I would like to propose a change to the way we vote. The change would be switching from visible casted votes to private / hidden votes until the date/time the vote closes, at which time everything will be made visible once again. This would block voting lobbying in various social channels based on possible outcomes, and would allow voting to run its course unaltered. The people that do want to share their vote option, can still do that in the mailing list where some already justify their votes. Looking forward for your thoughts on this, Stelian
Re: [PHP-DEV] Voting irregularities
Can we please stop with this? It's damaging to the language and the community. I am a strong believer of STH, no surprise there, but I do not think this thread should have been created. Is the php voting process uncontrolled and chaotic with no real count of voting members? Hell yes. This does not mean by far that this is the right time to discuss this. Let the RFCs go their way and once feature freeze is in and no more RFCs popping up for a while, the process can be discussed and optimised, if the case may be. All in all STH has turned into this big charade, and no matter which way it goes someone, there are going to be a lot of future friction and told you so's. In terms of managers, we do have a release manager, stick to that for the 7.0 release, re-evaluate after. My 2 cents, Stelian On Sun, Mar 15, 2015 at 8:56 PM, Thomas Bley ma...@thomasbley.de wrote: Which post says that we're turning PHP into Java I think there are people who want to switch from Java to PHP, maybe they feel easier with declare(strict...). Also in the past, some companies switched from PHP to Java because they wanted more strictness in their backend code. I don't like declare(strict...), but we should give it a chance in practice and then every userland developer can decide on his own if his programming style fits to it, or not. For me personally, I must admit that I am not using namespaces, traits and goto, but almost all other features of PHP :) Regards Thomas Derick Rethans wrote on 15.03.2015 20:07: Rowan Collins rowan.coll...@gmail.com schreef op 15 maart 2015 17:59:17 GMT+00:00: On 15/03/2015 14:19, Anthony Ferrara wrote: All, I ran some numbers on the current votes of the dual-mode vote right now. There were a number of voters that I didn't recognize. So I decided to pull some stats. The following voters never voted before the dual-mode RFC went up: dom - no eliw - no kguest - yes kk - no nohn - no oliver - yes richsage - yes sammywg - no spriebsch - no srain - no theseer - no zimt - no Some of these names I recognize from list (sammywg and eliw), but many I do not. The interesting thing happens when you look at the voting direction. Currently, the RFC is slightly losing 70:37 (65.4%). If we look at percentages, 4.2% of yes voters have never voted in a prior RFC. But a whopping 24.3% of no voters have never voted before. I think calling this an irregularity is going a bit far. I don't think it's going to far, if you have people with no clue writing this: https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB Which post says that we're turning PHP into Java. And to this misguided FUD post, that actively asks people to vote no, I can quite easily attribute a few more no votes of people that had never voted before... Too late to tighten up the rules for this one, but something is definitely not right with the current process. Cheers, Derick -- http://derickrethans.nl | http://xdebug.org twitter: @derickr and @xdebug -- 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] Basic STH - status unofficial poll
I voted no just because at this point no matter which way STH goes, it will end bad so I would rather not have it until people reconcile on something that works for all parties. On Sun, Mar 15, 2015 at 10:21 PM, Pierre Joye pierre@gmail.com wrote: On Mar 16, 2015 8:03 AM, Zeev Suraski z...@zend.com wrote: All, First, I decided not to propose Basic STH under my name, despite the fact I think that not committing to put it to a vote adds unneeded risk for delivering STH in PHP 7.0. Whether or not it’s put to a vote will be up to Bob. It is not up to any of us. If it is too late and as far as I remember it is, then it is over for any new rfc. Secondly, I do want to attempt to understand what will happen if when the Basic STH RFC goes to a vote at some later point in the future (which according to Bob, will happen if the Dual Mode RFC fails). If I see that Basic STH is going to fail, I’ll change my vote to be in favor of the Dual Mode STH RFC, call upon everyone to do the same, and retract my Coercive mode RFC. Then do it now. Accept that your RFC failed and stop trying yet another move to get it. This is really killing us. This unofficial-non-RFC poll is here: wiki.php.net/notrfc/scalar_type_hints Thanks, Zeev
Re: [PHP-DEV] Basic STH - status unofficial poll
Truth be told that might just be a record for number of no votes in a 10 minutes window! :) Also I thought this was all about elephants ... On Sun, Mar 15, 2015 at 10:40 PM, Zeev Suraski z...@zend.com wrote: Stelian, Respectfully, I think internals@ is being just a bit too uptight here. First, I did ask Bob before doing this, and while he said he thought it wasn't a good idea (mostly because of feedback such as yours) - he didn't 'block' me. Secondly, can we all relax a bit with the rules, RFCs, legalese and what's allowed and not allowed to do? It's a simple POLL. I'm not abusing anything, I'm not pretending it replaces the vote and I actually know there'd be at least some people that won't vote in the same way that they would in case Basic really comes up for a vote. It's to gauge the waters, nothing more, and nothing less. Last, it's completely identical to me asking on the list how people would vote in case Bob's RFC became available for a vote. Except it's a lot easier to track and much more likely to get a large number of responses. Let's not make an elephant out of a mouse. FWIW, so far I'm getting excellent cooperation from the Strict campers on this unofficial poll :) Zeev -Original Message- From: stelian.mocan...@gmail.com [mailto:stelian.mocan...@gmail.com] On Behalf Of Stelian Mocanita Sent: Sunday, March 15, 2015 11:11 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] Basic STH - status unofficial poll Now you are just pushing the limits and doing things your way. Bob clearly stated he does not want a vote and you want with an unofficial poll? You need to learn to let things go their course and not always push matters your way. I do not see how you can pull this move yet still be offended when people call you out on political moves. I hereby kindly ask you to retract this unofficial poll and let things go their way, whatever they might be. On Sun, Mar 15, 2015 at 10:03 PM, Zeev Suraski z...@zend.com wrote: All, First, I decided not to propose Basic STH under my name, despite the fact I think that not committing to put it to a vote adds unneeded risk for delivering STH in PHP 7.0. Whether or not it’s put to a vote will be up to Bob. Secondly, I do want to attempt to understand what will happen if when the Basic STH RFC goes to a vote at some later point in the future (which according to Bob, will happen if the Dual Mode RFC fails). If I see that Basic STH is going to fail, I’ll change my vote to be in favor of the Dual Mode STH RFC, call upon everyone to do the same, and retract my Coercive mode RFC. This unofficial-non-RFC poll is here: wiki.php.net/notrfc/scalar_type_hints Thanks, Zeev
Re: [PHP-DEV] Basic STH - status unofficial poll
Now you are just pushing the limits and doing things your way. Bob clearly stated he does not want a vote and you want with an unofficial poll? You need to learn to let things go their course and not always push matters your way. I do not see how you can pull this move yet still be offended when people call you out on political moves. I hereby kindly ask you to retract this unofficial poll and let things go their way, whatever they might be. On Sun, Mar 15, 2015 at 10:03 PM, Zeev Suraski z...@zend.com wrote: All, First, I decided not to propose Basic STH under my name, despite the fact I think that not committing to put it to a vote adds unneeded risk for delivering STH in PHP 7.0. Whether or not it’s put to a vote will be up to Bob. Secondly, I do want to attempt to understand what will happen if when the Basic STH RFC goes to a vote at some later point in the future (which according to Bob, will happen if the Dual Mode RFC fails). If I see that Basic STH is going to fail, I’ll change my vote to be in favor of the Dual Mode STH RFC, call upon everyone to do the same, and retract my Coercive mode RFC. This unofficial-non-RFC poll is here: wiki.php.net/notrfc/scalar_type_hints Thanks, Zeev
Re: [PHP-DEV] [RFC] Basic Scalar Types
So to get it clear for everyone: the right way is for internals to ignore community as a whole, stick to their own views and implement something nobody actually wants - just because there is no time - on the idea that something is better than nothing? Without pointing any fingers it sure looks like a stalling tactic where someone eventually gets what they want. Highly disappointed on this outcome. On Fri, Mar 13, 2015 at 6:20 PM, Eli e...@eliw.com wrote: Not that another +1 is needed, but I'm with Andi here. I do personally like this 3rd proposal as an option, if nothing else because it implements the 'simpler base' at the moment, and allows us, once people are used to this being part of the language, to continue to evolve later. And that evolution can be based upon our real world experience of using this 'base level' of typehinting for a while. Versus the more complicated versions, of which both Zeev's and Anthony's are. In each their own way. Eli On 3/13/15 1:17 AM, Andi Gutmans wrote: Agree and I would vote +1 on this even if I'd prefer coercive. It is a very valid option for a 7.0 and it is future proof. -- | Eli White | http://eliw.com/ | Twitter: EliW |
Re: [PHP-DEV] [RFC] Basic Scalar Types
Zeev, allow me to understand how this goes. Bob's discussions on the RFC started 2 days ago. Based on the current rules, the RFC can only go to vote after 2 weeks. That means in 12 days starting now. So we are either violating the RFC rules by pushing the vote tomorrow or we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes? Pointing at number 6 from https://wiki.php.net/rfc/howto On Fri, Mar 13, 2015 at 11:07 PM, Pierre Joye pierre@gmail.com wrote: On Mar 14, 2015 9:03 AM, Zeev Suraski z...@zend.com wrote: Maybe I was naïve, but I thought I had a better way to make both weak strict camps happy, By dropping strict despite all discussions, proposing a pandara box rfc by changing the casting rules and now suddenly proposing to go vote to yet another perfect RFC? Sorry, it does not help anyone and damages php, creates yet more issues. This is not a good call.
Re: [PHP-DEV] [RFC] Basic Scalar Types
So sticking to the rules is now playing law firm. The RFC Andreea proposed has been modified several times before going to vote. And we're not voting on her RFC, we're voting on Bob's that was proposed 2 days ago. I have a feeling that this will go to vote tomorrow though. On Fri, Mar 13, 2015 at 11:26 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: And none answered me... is this RFC gonna be allowed to enter on voting phase for 7.0 or not? This drastically changes my voted on STH v5 which ends EOD today. []s, On Fri, Mar 13, 2015 at 6:17 PM, Stelian Mocanita steli...@php.net wrote: Zeev, allow me to understand how this goes. Bob's discussions on the RFC started 2 days ago. Based on the current rules, the RFC can only go to vote after 2 weeks. That means in 12 days starting now. So we are either violating the RFC rules by pushing the vote tomorrow or we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes? Pointing at number 6 from https://wiki.php.net/rfc/howto On Fri, Mar 13, 2015 at 11:07 PM, Pierre Joye pierre@gmail.com wrote: On Mar 14, 2015 9:03 AM, Zeev Suraski z...@zend.com wrote: Maybe I was naïve, but I thought I had a better way to make both weak strict camps happy, By dropping strict despite all discussions, proposing a pandara box rfc by changing the casting rules and now suddenly proposing to go vote to yet another perfect RFC? Sorry, it does not help anyone and damages php, creates yet more issues. This is not a good call. -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] Re: A plea for unity on scalar types
Thanks Anthony for the thorough explanation and your view on the matter, highly appreciated. I am sure that long-term developers have gone through both ends of the strong types, either loving their lack while picking up php for the first time, either cursing it's lack later on along the way. As you mentioned you can pretty much do anything in PHP in both small setups or even enterprise - god I hate that word - so it would make sense to have something that gives both parties what they want. Having said this, I am truly hoping we can put an end to all this and have your current RFC in and move along. Regards Stelian On Fri, Mar 13, 2015 at 5:10 PM, Johannes Ott m...@deroetzi.de wrote: Thanks for the clear statement, which lights up the fog a little bit for. Watching out for a scalar typehints feature for round about 10 years without knowing about this internal list, I always was wondering what can be so complicated to implement it, because I already evaluated some different ways how to do this for my thesis. I already thought about a political reason for that. I'm with you that your Dual RFC is the right solution to satisfy the needs of all of the three mentioned groups in my opinion as well. I would give a clear +1 to it, but I don't have any voting karma yet! Regards -- DerOetzi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Basic Scalar Types
Dmitry, I tend to disagree with many people wanting this over nothing. It's a big enough topic, that raised waives in the community, to be treated properly and not just throw it in before feature freeze, so I agree with Nikita on this one. My view on it is that if both RFC's fail, the feature should not be in 7.0 and have a proper solution for 7.x, what ever that x might be, a solution that satisfies both internals and userland. On that topic, it's a shame that all this work and effort might be thrown away and at the end of the day we would be left with nothing. Regards, Stelian On Thu, Mar 12, 2015 at 12:06 AM, Dmitry Stogov dmi...@zend.com wrote: On Thu, Mar 12, 2015 at 1:53 AM, Nikita Popov nikita@gmail.com wrote: On Wed, Mar 11, 2015 at 10:28 PM, Bob Weinand bobw...@hotmail.com wrote: Hi all, after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail. Thus, I'd like to come up with a fallback proposal in case both proposals fail: https://wiki.php.net/rfc/basic_scalar_types It shouldn't prevent any future improvements and still give use all the advantages of scalar types. Before I even start thinking about this, I'd like to have clarification as to whether this RFC is still eligible for targeting the PHP 7.0 release. The currently accepted interpretation is that all RFC votes must have started by March 15th, which is irreconcilable with an RFC that was only submitted today. Does this mean that we're delaying the PHP 7 schedule by two weeks? I feel like this topic is getting out of control. It's been discussed for months, now we had one vote on Andrea's withdrawn proposal, then another vote on Anthony's proposal, then another vote on the Zeev et al proposal - and then we're going to have another one on Bob's proposal? With every vote taking another couple of weeks. Hey, maybe I should also submit a STH proposal that we can vote on after that? If both Anthony's and Zeev's proposal fail, I would recommend to just drop this topic for 7.0 and discuss it again for PHP 7.1. The necessary forward-compatibility changes to allow that are already proposed in another RFC. Bob proposes the base common part of both other RFCs. It actually had to be proposed in first place. I would prefer this instead of nothing. I think many people think the same. Thanks. Dmitry. Nikita
Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC
Hi Shawn,
My opinion is that even though the @ operator should be deprecated in
further along the line removed, it should not be repurposed for anything,
it has too much legacy imho.
While a shortcut might be a good idea, I personally favour the $this-var
syntax just for muscle memory if nothing else.
Stelian
On Mon, Mar 9, 2015 at 11:54 AM, reeze re...@php.net wrote:
Hi,
On 9 March 2015 at 17:43, Shawn McCool sh...@heybigname.com wrote:
I've never submitted an RFC. Whether or not you're interested in the
feature, please consider giving me feedback on the RFC itself so that I
can
better understand how to succeed in the process.
== PHP RFC: Instance Variable Sugar ==
* Version: 0.1
* Date: 2015-03-09
* Author: Shawn McCool, sh...@heybigname.com
* Status: In Discussion
= Summary =
In order to access instance variables, one must use the `$this-` prefix.
The problem with this is that it reduces expressiveness in the language
and
increases the amount of unnecessary decoration, reducing readability.
This might decrease readability, since we already comfortable with the
syntax $this-something, in my opinion
This RFC proposes a single character syntax sugar form of `$this-`.
Instead, an `@` can be used to reference instance variables.
The @ replaces the normal $ variable prefix.
= Example =
file php MyClass.php
?php
class Addition {
private $number
public function __construct($number) {
@number = $number;
}
public function original() {
return @number;
}
public function addTo($amount) {
return @number + $amount;
this is a BC break. this is the same as constant number + $amount. so this
syntax is not feasible.
}
}
/file
= Backwards Compatibility =
Leave `$this-` available.
= Proposed PHP Version(s) =
This is proposed for the next PHP x, currently PHP 7.
--
Shawn McCool | Big Name
sh...@heybigname.com
heybigname.com
--
Reeze Xia
http://reeze.cn
Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC
On top of the cultural disposition, there is also the fact that things
should not be removed from the language without deprecating them, so at
best 7.0 would emit and E_DEPRECATED for the usage of @.
- Stelian
On Mon, Mar 9, 2015 at 3:31 PM, Kalle Sommer Nielsen ka...@php.net wrote:
Hi
2015-03-09 15:11 GMT+01:00 Shawn McCool sh...@heybigname.com:
I guess that if I thought that PHP would change its scoping, I would have
tried for that.
Well take this code into consideration:
?php
class A {
protected $b;
function c($b) {
$b = $b; // does not work
}
function d($d) {
$b = $d; // works
}
}
?
A::c() will fail because the parameter $b conflicts with the property
A::$b, but example works because the parameter is now named $d, and
therefore making $b available for assignment (should probably
internally be implemented as a reference to $this-b), but only on
demand (JIT) to avoid extra memory consumption.
This approach may seem quirky at first, but it doesn't add any new
syntax but some magic behind the scenes. Although I personally am not
a huge fan of magic variables like that, it is possible.
--
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] Reviving scalar type hints
Thanks Sara for taking over, For myself both ?php strict would seal the deal, but use strict; is also an option I would endorse. Despite mentioning not scoping union types, I feel like a numeric type would make a lot of sense and bring in more consensus to the list, fixing the all famous sin() and such issues which I also see as a slight drudgery to keep casting. Regards, Stelian On Tue, Feb 17, 2015 at 1:35 AM, Dan Ackroyd dan...@basereality.com wrote: On 17 February 2015 at 00:22, Nikita Popov nikita@gmail.com wrote: Thank you for taking over. I like use strict and declare as top-level only most. That would be this no vote changed to a yes. And I'd also like to say thank you Sara for taking over. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I quit.
Hi Andrea, Thank you for all your hard word and time you've put into this project and it saddens me to see you decide that, but I do understand where you come from. Looking forward for your next project and I wish it will bring you more recognition than this one did. Best regards, Stelian On Mon, Feb 16, 2015 at 12:23 AM, François Laupretre franc...@php.net wrote: De : Andrea Faulds [mailto:a...@ajf.me] So, thank you, PHP community. It has been a wonderful 2 years. That's very sad, but I understand it had gone too far. You're more important than any software project, take care of yourself. Unfortunately, the 'toxic kindergarden' claimed another victim. Not the first one, probably not the last one. And nobody says that's enough. Nobody says it cannot continue this way, losing the best ones. No reaction. No leadership. No education. No balls. It really gets me tired and angry. Who's next ? Good luck, Andrea. Hope to welcome you back soon. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
Hello Marcio, I am inclined to vote no for a couple of reasons: 1. This is not a BC-break, I would move the vote to PHP 7.1. The reasoning behind this is that the tools in the ecosystem will have a lot of work to get on par with PHP 7 (talking here about stuff like phpmd, phpcpd, phploc, newrelic, codeclimate, ides, etc). Since this is not as resonant as the other changes for 7, I would give those people some breathing room. 2. I am not a big fan of the syntax, I would much more like a python style syntax (yes, I am aware it requires a new reserver keyword) What are your thoughts on this? Stelian On Thu, Feb 12, 2015 at 3:38 PM, reeze re...@php.net wrote: Definitely +1 for me. That what I proposed before. you make it happened ;-) On 12 February 2015 at 22:25, Marcio Almada marcio.w...@gmail.com wrote: Yup sure. We are going to vote yes (behind my nickname). However, while I agree with all your arguments, we have more syntax and more semantics, it's kind of confusing. But it's a small one, so +1 for us. I bet there is no way to add such a feature without adding at least a small amount of syntax, and that's why I aimed for the minimal approach. Also, there is no better time to have it added other than on a major version release. Thanks for your questions and your vote :) -- Reeze Xia http://reeze.cn
Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
On Fri, Feb 13, 2015 at 12:13 AM, Marcio Almada marcio.w...@gmail.com wrote: Hi Stellan, Hello Marcio, I am inclined to vote no for a couple of reasons: 1. This is not a BC-break, I would move the vote to PHP 7.1. The reasoning behind this is that the tools in the ecosystem will have a lot of work to get on par with PHP 7 (talking here about stuff like phpmd, phpcpd, phploc, newrelic, codeclimate, ides, etc). Since this is not as resonant as the other changes for 7, I would give those people some breathing room. Well, we already have new shiny features for PHP that would require updates: for instance the return typehints and possibly the scalar type hints. Any code analyzer that would like to stay relevant will need to update anyway and perhaps updating these tools is much easier than you think :) if you see the patch it's quite minimal and the syntax is easy to parse. I am not saying your RFC is the deal breaker, I am saying that the overall effort grows. 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. Other reasons to show you this is not a blocker and tailoring the RFC for 7.1 is not the best choice: - It will take a while until we see projects with PHP7 as a minimum version requirements so if we want the feature it's a good idea to add it to a major release. - Feature freeze date is possibly March, 2015, possible release date is Mid October 201. This means we will have plenty of time to update tooling. This should not hold any language :) 2. I am not a big fan of the syntax, I would much more like a python style syntax (yes, I am aware it requires a new reserver keyword) :) I have a hunch that a python copy syntax will not be proposed because of the BC break you just mentioned ^ 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 This is a very basic feature and I strongly believe that, after all the research and discussion, it's a good fit for PHP. Perhaps you might want to read the discussion again before take your decision. See the previously discarded options and the reasons why they were discarded. Maybe you might end up agreeing that the current proposed syntax is a good choice. Thanks for opening dialog and bringing legit questions before take a decision. Good voting! Thanks for taking the time to read through and explain your angle. Sincerely, Márcio Almada
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Sending people who want to have more structure in the language to Java is downright bad, not to mention that it sounds completely dictatorial. I would just put that in the next Zend newsletter to make it clear for your customers that there is a saner option. Stelian On Fri, Feb 6, 2015 at 12:57 AM, Andi Gutmans a...@zend.com wrote: The folks who really want all this great strict typing should head over to Oracle.com and download free open-source Java? I hear it's got a lot of strict typing features in it. Only downside is that it'll take them 10x longer to complete their projects. OK sorry. Had to say that :) I realize it's not the same... Andrea, while I don't agree with what you say I accept it. *But* exactly for the reasons you state (the big divide) we should also have a weak type hinting option to vote for in parallel. If you feel morally unable to do that then I can copy your work and just have another RFC running in parallel but I think that would do a disservice to the good work you've done. Andi On Thu, Feb 5, 2015 at 3:47 PM, Andrea Faulds a...@ajf.me wrote: Hi Andi, On 5 Feb 2015, at 23:22, Andi Gutmans a...@zend.com wrote: I have to say I’m pretty disappointed at the opening of the vote. We had a pretty good RFC (thank you) for weak type hinting which was aligned with the spirit of PHP and everyone was able to rally around it. This is far from true. Some people on internals were happy, but only some, and everywhere outside internals I looked, the reception was far more negative. This has now been morphed into something very hard to swallow and IMO having such a declare(…) syntax will be ridiculed by the broader app dev community until the end of time… Nobody mocks Perl or JS for use strict. But even that syntax aside (it’s only syntax after all), I think we lost the ability to reach consensus on something so important to everyone which we haven’t been able to come to agreement on for over 10 years. Finally it was there, in reach and you made a 180 degree turn. “Consensus” is exaggerated. There was no consensus and to claim there was is to ignore the reality that the PHP community is divided over this issue. I’d love to say that everyone loves weak type hints and if that version had passed we’d all be dancing around happy holding hands, but the reception was not uniformly positive, not even close, and that’s just on internals. I think it’d be so much easier for us to implement weak type hinting. Have everyone rally around it. Be happy and then learn and see whether an additional mechanism is really necessary. Who’d be happy? I realise you and Zeev are big fans of weak types, as are many others, but there are also a lot of PHP developers who vehemently disagree with you. We could even add an E_STRICT_TYPES error_reporting flag to help folks “debug” their code if they so wish to see if there are any hotspots in their code they may want to take a look at - again not necessarily an error but maybe a debugging tool. Global error handlers affect all code the interpreter runs, which is why we’ve looked down on them in recent times. But net, net - why not just implement the thing everyone can agree on. Everyone doesn’t agree on it. If everyone did agree on it, v0.1 of the RFC would have been the one that went to vote. Have something really good in the spirit of the PHP Language for PHP 7 and learn how people leverage that… The reality is that for the majority of the Web community “1” coming in from HTTP should be accepted as a 1. Period. It’s very well and good you claiming that the “majority” agree, but this does not match my experiences. The PHP community is not a single, homogenous entity. It is very difficult to judge. I voted “no” but I will vote “yes” for the competing RFC which is 80% of your RFC. Why are we not given that option?? Because I cannot in good conscience push through something in the name of “consensus” which does not even approach it. -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hello everyone, Might I suggest community feedback on this one in a reddit thread? My guess is that even though a lot of applications out there are still PHP 4 ctor reliant, a very low percentage of these applications might be under active development. Best, Stelian On Fri, Jan 16, 2015 at 12:28 PM, Derick Rethans der...@php.net wrote: On Thu, 15 Jan 2015, Levi Morrison wrote: On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@ajf.me wrote: Upon further thought, I’m not super-enthusiastic about this. As has been pointed out, it’s a pretty serious BC break, whether code can be automatically updated or not. PHP 4 constructors may be obsolete, but an awful lot of code uses them. A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working. Possibly. The reality of my position is that I am unhappy about our current constructor situation. Having `__construct` and only half-heartedly supporting old-style constructors for the next several years (maybe ten?) does not sound good at all. Removing one of the constructors is a nicer end product than fully supporting both, in my opinion, which is why I proposed dropping it. Instead of just dropping it, which would likely generate odd bugs, declaring an old style constructor should *tell* you it's no longer working- perhaps with as strong of an error as an E_COMPILE_ERROR—atleast for PHP 7. Just removing it support would, IMO, be silly. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Florian Margaine wrote on 16/01/2015 13:01: Hi Stelian, Stelian Mocanita writes: Hello everyone, Might I suggest community feedback on this one in a reddit thread? My guess is that even though a lot of applications out there are still PHP 4 ctor reliant, a very low percentage of these applications might be under active development. Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. Completely agree, but you get once in N years a chance to do some cleanup on the language. If people expect no BC breaks on major versions, when is the time for the cleanup? That's one thing. The other thing is that there's a flow in your logic. If you want the bug/security/performance fixes, it means you are already running latest stable and for some reason you completely ignored all of the deprecation warnings until now. I think we can both agree on this being a bit far-fetched. Not to mention that all the old ctor fatal errors can be fixed with an automated scripts that replaces the old ctors with the new ones. Stelian
Re: [PHP-DEV] [RFC] Improve array to string conversion
I would vote for the first option and entirely deprecate the array to string conversion. As far as I can see there is no real world use-case for it and most of the time it does more harm than good. Stelian On Sun, Jan 11, 2015 at 2:29 PM, F N Laupretre nf.laupre...@yahoo.fr wrote: Hi, A new RFC for PHP7 : https://wiki.php.net/rfc/array-to-string Not implemented yet, but the PR is available for comments : https://github.com/php/php-src/pull/991 Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rand(), mt_rand() and limits
All this sounds really good, and I am all for uniformity when the downsides are not too much to handle. I would have one suggestion though, and that would be to add deprecation notices on every mt_ alias so in time they can be safely removed and cleaning everything up. On Sun, Jan 11, 2015 at 11:35 PM, François Laupretre franc...@tekwire.net wrote: De : Andrea Faulds [mailto:a...@ajf.me] Would that sound good? That sounds very good to me :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
Hi Sara, Obviously a great idea that would make a lot of people's life easier all around. One question though? How would api extensions be handled on both sides and would it be at all possible to keep the APIs consistent across hvvm / php versions? I imagine that there would need to be consensus on both php / hhvm teams to add any extra functionality, is this correct? On Sat, Jan 10, 2015 at 5:14 AM, Sara Golemon poll...@php.net wrote: On Fri, Jan 9, 2015 at 5:48 PM, Paul Dragoonis dragoo...@gmail.com wrote: Somewhat Pie in the sky but at the same time also achievable with good planning and design. I'd support this definitely and this abstraction layer would solve constant maintainability of extensions by not having to update themselves constantly to support latest versions of PHP due to a lack of abstraction. Yep. Exactly what I'm thinking. I forsee defining this PHP-Native Interface (I hereby dub it PNI) as part of the php-langspec such that part of being a conforming implementation includes supporting this API. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
