On Fri, Aug 9, 2019 at 7:08 PM Larry Garfield
wrote:
> On Fri, Aug 9, 2019, at 2:54 PM, Zeev Suraski wrote:
> > During the discussion of the P++ proposal (
> > https://externals.io/message/106453), it became painfully clear that
> this
> > idea did little, so far, to bring peace to the galaxy.
>
On Fri, Aug 9, 2019, at 2:54 PM, Zeev Suraski wrote:
> During the discussion of the P++ proposal (
> https://externals.io/message/106453), it became painfully clear that this
> idea did little, so far, to bring peace to the galaxy.
>
> However, based on a lot of the feedback, both on internals@
On Fri, Aug 9, 2019 at 4:30 PM Zeev Suraski wrote:
> In the spirit of my response to Bob, I added a new FAQ: "How does this
> differ from Nikita's Editions idea?"
>
>
"""Related to rollout - the Editions approach doesn't allow for just two
dialects - but any number of dialects. We could have a
On 10 Aug 2019, at 1:51, Sara Golemon mailto:poll...@php.net>>
wrote:
On Fri, Aug 9, 2019 at 4:58 PM Zeev Suraski mailto:z...@php.net>>
wrote:
As Bob pointed out I'm rusty, but I do think that we can solve the short
tags issue in this way. At the lexer level, if we see the tag, we
set
On Fri, Aug 9, 2019 at 4:58 PM Zeev Suraski wrote:
> As Bob pointed out I'm rusty, but I do think that we can solve the short
> tags issue in this way. At the lexer level, if we see the tag, we
> set short tags to off for the scope of the file before moving forward. But
> more importantly,
On Fri, Aug 9, 2019 at 4:30 PM Mark Randall wrote:
> On 09/08/2019 22:02, Sara Golemon wrote:
> > 2. Strict(er) typing - I'm not sure, on the surface, what future
> expansions
> > we'd plan for in this area which couldn't fit into standard PHP in a non
> > BC-breaking way.
>
> Union types and
On Sat, Aug 10, 2019 at 12:03 AM Sara Golemon wrote:
> On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski wrote:
>
> > It's available here: https://wiki.php.net/pplusplus/faq
> >
> >
> It's possible I missed something while on holiday. There are certainly a
> lot of messages to page through. I dig
On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov wrote:
> This is basically what I have been advocating for a while now already,
> somewhat hidden between all the other noise of the "namespace-scoped
> declares" thread. The model I would like to follow are Rust editions (
>
I do completely agree with this and would like to be part of it. I am
really frustrated to see old developers shrug every time I talk about php.
I am enthusiastic about our language, the language I started coding with
and the language that evolved in years while I was learning it.
2 years ago,
On 09/08/2019 22:02, Sara Golemon wrote:
2. Strict(er) typing - I'm not sure, on the surface, what future expansions
we'd plan for in this area which couldn't fit into standard PHP in a non
BC-breaking way.
Union types and general reflection do spring to mind on this. I assume
any APIs using
On Fri, Aug 9, 2019 at 11:27 PM Mark Randall wrote:
> On 09/08/2019 20:54, Zeev Suraski wrote:
> > It's available here: https://wiki.php.net/pplusplus/faq
>
> I am now even more confused.
>
> How is this drastically different to Nikita's suggestion of setting a
> compiler version via rust-like
It seems that the only people in favor of making this split, either as a
fork, directive or otherwise, are the people that do not intend to switch
to this new flavor.
So why not the other way around, with a new flavor named "PHP classic"?
Those who do not want to participate in the progression of
Bob,
I appreciate your candid email. Please see responses below.
On Fri, Aug 9, 2019 at 11:12 PM Bob Weinand wrote:
> It's clearly quite a feat, your contributions to PHP 3 and PHP 4.
> This does not give you any authority now.
While I completely disagree, that is completely beside the
On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski wrote:
> It's available here: https://wiki.php.net/pplusplus/faq
>
>
It's possible I missed something while on holiday. There are certainly a
lot of messages to page through. I dig the idea of resolving this
tug-of-war between progress and BC, but
On 09/08/2019 20:54, Zeev Suraski wrote:
It's available here: https://wiki.php.net/pplusplus/faq
I am now even more confused.
How is this drastically different to Nikita's suggestion of setting a
compiler version via rust-like version declares?
It seems to me that it's just moving the
Hey Zeev,
> Am 09.08.2019 um 19:44 schrieb Zeev Suraski :
>
> On Fri, Aug 9, 2019 at 7:44 PM Dan Ackroyd wrote:
>
>> On Fri, 9 Aug 2019 at 17:10, Zeev Suraski wrote:
>>>
>>> we’re discussing whether it makes sense to introduce a sister language
>> to PHP.
>>
>> Zeev also wrote:
>>> It will
During the discussion of the P++ proposal (
https://externals.io/message/106453), it became painfully clear that this
idea did little, so far, to bring peace to the galaxy.
However, based on a lot of the feedback, both on internals@ and elsewhere -
it seems that a lot of people simply didn't
On Fri, Aug 9, 2019 at 3:02 AM Joe Watkins wrote:
> Morning all,
>
> First, I want to say that I don't think the polarisation claimed to be
> occurring is actually occurring. The vast majority of internals voters
> appear to judge each RFC on it's own merit, while some of them give more
> weight
On Fri, Aug 9, 2019 at 7:44 PM Dan Ackroyd wrote:
> On Fri, 9 Aug 2019 at 17:10, Zeev Suraski wrote:
> >
> > we’re discussing whether it makes sense to introduce a sister language
> to PHP.
>
> Zeev also wrote:
> > It will take no additional resources,
>
> First, those two statements are
While I think there still might be a seed of a good idea here, I am
not going to pursue it at this time. I believe that it could be
misused to distract from productive conversations.
Before it can be discussed further, the PHP project needs to have a
Code of Conduct to prevent people who are in
On Fri, 9 Aug 2019 at 17:10, Zeev Suraski wrote:
>
> we’re discussing whether it makes sense to introduce a sister language to PHP.
Zeev also wrote:
> It will take no additional resources,
First, those two statements are mutually exclusive.
Second, the idea of keeping PHP as it currently is,
Hello,
On Thu, 8 Aug 2019 at 22:17, Zeev Suraski wrote:
>
> [... and not in the Sith Lord kind of way.]
>
> Looking at some of the recent (& not so recent) discussions on internals@,
> some of the recent proposals, as well as some of the statements made
> regarding the future direction of the
Sent from my tablet
> On 9 Aug 2019, at 19:02, Mark Randall wrote:
>
>> On 09/08/2019 08:15, Zeev Suraski wrote:
>> You seem to believe that C++ is inherently superior to C. And it's
>> entirely within your right.
>> However, there are projects - to this date - that prefer C to C++ for a
>>
On 09/08/2019 08:15, Zeev Suraski wrote:
You seem to believe that C++ is inherently superior to C. And it's
entirely within your right.
However, there are projects - to this date - that prefer C to C++ for a
variety of reasons. PHP is one of them, and others include the Linux
kernel, redis,
First of all, Amen to Arvids Godjuks. I think managed to clearly convey the
opinion of a majority of the PHP community.
Some small things I like to add. IMHO the backward-incompatible changes that
are currently discussed aren't about radical changes, but incremental
improvements.
There
On Fri, Aug 9, 2019 at 4:12 PM Dan Ackroyd wrote:
> On Thu, 8 Aug 2019 at 21:17, Zeev Suraski wrote:
> >
> > My goal is to have two sister languages, with both PHP and P++
> > being equal among equals
>
> PHP internals is already lacking programming resources to do
> everything we want to be
On Fri, Aug 9, 2019 at 10:22 AM Nikita Popov wrote:
> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote:
>
> I think this part is unrealistic from a simple manpower perspective. We
> have something like ~2 full time developers working on PHP. Even if you can
> rally some additional interest
> Disabling short tags now is done with "an explicit directive" (there has to
> be a specific ini file with a specific setting 'short_open_tag = 0').
> Isn't this the same "situation when you create a separate file with an
> explicit directive"?
No, it's not. `php.ini` is outside of project
On Fri, Aug 9, 2019 at 3:43 PM Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> I've got an impression that you're the only one who sees a good direction
> in splitting the language in two different dialects and am not sure about
> sincere intentions.
>
This isn't splitting the
On Thu, 8 Aug 2019 at 21:17, Zeev Suraski wrote:
>
> My goal is to have two sister languages, with both PHP and P++
> being equal among equals
PHP internals is already lacking programming resources to do
everything we want to be doing.
Maintaining two versions at once would be more work, so
> I'm not sure what you're saying here exactly, but if you are suggesting
> that PHP.future, whatever this future version number is - is going to be a
> strictly typed language, with total disregard for BC /../
I'm suggesting that PHP could stop worrying about "super legacy code which uses
short
Hi Zeev,
pt., 9 sie 2019, 14:23 użytkownik Zeev Suraski napisał:
>
>
> On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> Hi Sergey,
>>
>> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev > >
>> napisał:
>>
>> > As I understand, in P++ it was
On Fri, Aug 9, 2019 at 1:44 PM Robert Korulczyk wrote:
> > I think it should also be pointed out that there's nothing stopping
> anyone
> > from forking PHP into a new project as Zeev described and maintain
> feature
> > parity. As I understand, the reason something like this hasn't happened
>
On 09/08/2019 13:07, Zeev Suraski wrote:
It's very, very different.
With this approach, even down the line in 2029, PHP remains PHP. None of
us has a crystal ball to predict the future, but my guess is that WordPress
will stick with PHP, and not move to P++. Based on feedback - Laravel (the
> This does not explain how someone could use that feature *by accident*. I gave
> an example where you can use short open tags by accident, and it is really
> easy
> (the most popular IDE sometimes generates code with short open tags) and hard
> to notice (it is not easy to spot a difference
On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> Hi Sergey,
>
> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev
> napisał:
>
> > As I understand, in P++ it was planned to drop the legacy code, add new
> > functionality and painlessly implement BC.
>
On Fri, Aug 9, 2019 at 10:40 AM Sergey Panteleev
wrote:
> As I understand, in P++ it was planned to drop the legacy code,
Correct.
> add new functionality
Correct.
> and painlessly implement BC.
>
Probably correct - but to phrase it more accurately - when we introduce P++
- we won't be
On 09/08/2019 08:15, Zeev Suraski wrote:
I'm unable to follow that part either. Would appreciate some further
elaboration to make it clearer what you have in mind in these three
paragraphs...
My read of what Nikita was suggesting was some kind of per-file or
per-package versioning system
> I did mention such example with the 'engine' setting (
> https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's
> PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik
> it's sapi specific) but technically it can happen just in one "hard to
> notice"
> -Original Message-
> From: Robert Korulczyk [mailto:rob...@korulczyk.pl]
>
>
> Can you give an example where using `.user.ini` may create unexpected and hard
> to notice code leaks?
I did mention such example with the 'engine' setting (
> I think it should also be pointed out that there's nothing stopping anyone
> from forking PHP into a new project as Zeev described and maintain feature
> parity. As I understand, the reason something like this hasn't happened
> already is because it would involve a ton of work and nobody wants
> Argument for "only a particular code path in a particular environment" is
> somewhat weak because in that case why does even ' .user.ini' feature exists
> (especially in apache sapi where you can even do engine = 0) as it also can
> lead to wildly different language behaviour?
Can you give
чт, 8 авг. 2019 г. в 22:17, Zeev Suraski :
> [... and not in the Sith Lord kind of way.]
>
> *snip*
>
> Thoughts?
>
> Zeev
>
Apparently, this exists: "ezmlm-reject: fatal: Sorry, I don't accept
messages larger than 3 bytes (#5.2.3)", so re-sending with Zeev's part
sniped out :)
Good day
Hi Sergey,
pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev
napisał:
> As I understand, in P++ it was planned to drop the legacy code, add new
> functionality and painlessly implement BC.
>
> Who wants – migrates the PHP project in P++, who doesn't – continues to
> use PHP.
>
> New projects,
As I understand, in P++ it was planned to drop the legacy code, add new
functionality and painlessly implement BC.
Who wants – migrates the PHP project in P++, who doesn't – continues to use PHP.
New projects, for example, will use P++ already.
Well, how is this different from the new version
*alongside patch
Cheers
Joe
On Fri, 9 Aug 2019, 09:33 Kris Craig, wrote:
> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrote:
>
> > On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote:
> >
> > >
> > >
> > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov
> > wrote:
> > >
> > >> This is
On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrote:
> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote:
>
> >
> >
> > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov
> wrote:
> >
> >> This is basically what I have been advocating for a while now already,
> >> somewhat hidden between all the
On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote:
>
>
> On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov wrote:
>
>> This is basically what I have been advocating for a while now already,
>> somewhat hidden between all the other noise of the "namespace-scoped
>> declares" thread. The model I
Joe,
Top posting on purpose because you seem to focus on the 'overnight' element
while not understanding quite what I meant (I'll take the blame for that) -
and therefore deriving irrelevant conclusions.
When I'm saying "overnight", I mean from the end users' perspective. In
the same way that
On Fri, Aug 9, 2019 at 2:53 AM Mark Randall wrote:
> On 09/08/2019 00:08, Zeev Suraski wrote:
> > 2. Different people have different preferences. There's a reason that
> not
> > everyone is using the same language, or have the same mobile phone or the
> > same car. Something it's not
Morning all,
First, I want to say that I don't think the polarisation claimed to be
occurring is actually occurring. The vast majority of internals voters
appear to judge each RFC on it's own merit, while some of them give more
weight to retaining bc than others and that effects their vote, they
> On 9 Aug 2019, at 12:11, Brent wrote:
>
> Hi Zeev
>
> Happy to see this proposal pop up, it's good to know that the "other side" is
> also open for long-term solutions. I think there needs to be a thorough
> analysis about the pros and cons of the two paths to take: a sister language
>
52 matches
Mail list logo
