Re: [PHP-DEV] Re: P++: FAQ

  106528
August 10, 2019 15:20 guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")
Hi all,

I tried as much as I could to stay away from this discussion. My
personal take is that breaking the language in two is a *really bad
idea* (shouldn't I have put caps here instead?).
Anyway, people are commenting a lot on features that adds a feature to
the language, but nothing was being spoken about scenarios where
severe internals changes would be required. Zeev, sorry for taking you
as the guinea pig here, but since you were the one that started this
whole thread, I think it's fair to ask you directly.

1- How would you envision a shared runtime between PHP and P++, in the
case that this new evolved solution decides to support objects as keys
in array structure? This fundamentally changes internals, and a
drastic change to both runtime of PHP and P++ would be required.

2- How would you envision injecting an actual namespace structure,
allowing scoping support for namespaces? FYI, this is what blocked me
to finish class visibility in https://github.com/php/php-src/pull/947
It'd require drastic changes in both PHP runtime and P++ too.

I have added 2 small samples (feel free to ask me if you need a few
more) where in order to add a feature in P++, changes to the way PHP
operated would have to change too.

The only I see this to operate is either P++ re-implementing the same
PHP structures in order to evolve, leading to a full fork becoming
more attractive, or compromises in P++ (like unable to support a given
feature) because PHP would make it set back.

Please let me know your thoughts on this.

Cheers,

On Sat, Aug 10, 2019 at 11:05 AM Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> > On Sat, Aug 10, 2019 at 5:37 AM Andrea Faulds <ajf@ajf.me> wrote: > > > As the person who initially proposed and implemented strict_types, I > > think this is heading in the wrong direction. Perhaps that directive was > > a mistake, if it will lead to so many attempts inspired by it to > > fragment the language, including this one. Personally, I don't actually > > want a language like C++ or Java. PHP's flexibility is great, and I > > think splitting the language means going in a direction where you are > > forced to have everything be strict or nothing be. PHP++ sounds like > > Hack, but in mainline. I think it'll end up a mess in the long term. > > > > Yes, I would suspect it would get a bit weird having a AnythingGoes > vs. NothingGoes barrier in the code like that. Forcing a balance, even > if sometimes the arguments get rather heated (and they were just as > heated, if not more so 20+ years ago), keeps everyone on the same > page and working on the same code-base without the us vs. them > situation that is bound to creep in. > > -Rasmus
-- Guilherme Blanco SVP Technology at Statflo Inc. Mobile: +1 647 232 5599
  106541
August 11, 2019 10:36 zeev@php.net (Zeev Suraski)
On Sat, Aug 10, 2019 at 6:21 PM guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> 1- How would you envision a shared runtime between PHP and P++, in the > case that this new evolved solution decides to support objects as keys > in array structure? This fundamentally changes internals, and a > drastic change to both runtime of PHP and P++ would be required. >
Why would that only make it into P++ and not PHP? Things which are sensible to both dialects should go into both dialects. 2- How would you envision injecting an actual namespace structure,
> allowing scoping support for namespaces? FYI, this is what blocked me > to finish class visibility in https://github.com/php/php-src/pull/947 > It'd require drastic changes in both PHP runtime and P++ too. >
I don't think we have an answer for that, but I also think it's an orthogonal question. It applies at the exact same way to the Editions. The only I see this to operate is either P++ re-implementing the same
> PHP structures in order to evolve, leading to a full fork becoming > more attractive, or compromises in P++ (like unable to support a given > feature) because PHP would make it set back. >
While I think that the deltas would be a lot smaller than something we should lose sleep over in terms of maintenance overhead - this will primarily depend on the substance of what we'd want to change - and not on how we package it. Whether we go for feature-specific declare()s, Editions, or P++ - makes little to no impact on the complexity of the code base. In fact, if anything - having an all-or-nothing option is likely to make the engine code simpler to develop and maintain, as instead of a huge number (per-feature) or medium number (Editions) of combinations that need to be designed to work together, supported and tested - we'd have just two. Do you view this differently? Thanks for the feedback! Zeev
  106544
August 11, 2019 12:51 arnold.adaniels.nl@gmail.com (Arnold Daniels)
The `strict_types` directive is limited to applying strict type checking, throwing a TypeError instead of doing implicit type casting.

The strict operators RFC is trying to do the same. Unfortunately there are a view of cases where this isn't easily possible and the statement will have a different result based on the flag. After a fierce discussion, the general consensus is that this should be minimized as much as possible (if at all).

With bc-breaking changes, there has always had a similar notion. The old code should have the same effect or throw an error. Exceptions to this exist, but are rare.

The P++ and edition proposals go completely against this premise.
---

Secondly, introducing such a dialect would ultimately break up the language and stagnate the progression of PHP in general. For instance, I'd fear that something like the deprecation of the left-associative ternary operator would not make it into PHP 8, but instead would be forced towards the P++ dialect. Even though this has nothing to do with loose vs strict types.
---

We should look and discuss to find alternatives that allow PHP to progress, but where bc-breaking changes result in an error (as much as possible) and do not (radically) change the behavior of PHP.

[Arnold Daniels - Chat @ Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=4202n)	[4202n]

On August 11, 2019 at 10:36 GMT, Zeev Suraski <zeev@php.net> wrote: