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
wrote:
> Hi,
>
> when I modify a DateTime object and add or subtract weekdays, it happens
> that the curr
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 wrote:
> Stelian Mocanita wrote:
> >
> > I would like to ask what on your th
ver 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
wrote:
>
>
> On 22 April 2015 at 11:24, Peter Cowburn wrote:
>
>> cc-ing doc list
>>
>> O
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.ph
> 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
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 v
sponses.
>
> 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...@g
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 wrote:
> On Mar 16, 2015 8:03 AM, "Zeev Suraski" wrote:
> >
> > All,
>
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
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 no
gh.
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.
>
>
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 a
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
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 yo
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 sho
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 wrote:
> Hi
>
> 2015-03-09 15:
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 nothi
Thanks Sara for taking over,
For myself both wrote:
> On 17 February 2015 at 00:22, Nikita Popov 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 Sa
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 Mo
On Fri, Feb 13, 2015 at 12:13 AM, Marcio Almada
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 wo
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
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 A
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 sti
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
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
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
wrote:
> Hi,
>
> A new RFC for PHP7 : ht
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
27 matches
Mail list logo
