Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106519
MIME-Version: 1.0
References: <CAJHtznw0eKbBNJo9TnDwZvvbMMFt5mCo=+SpKLw0zYzq9tKWZA@mail.gmail.com>
 <71581e93-e38a-47b2-9d89-e9ed5850511a@www.fastmail.com>
In-Reply-To: <71581e93-e38a-47b2-9d89-e9ed5850511a@www.fastmail.com>
Date: Fri, 9 Aug 2019 19:28:10 -0400
Message-ID: <CAPKYkKz7WiJG+th5gyKae3LsKpCEi1cL+DP4jVmF+gJpqvTJOA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: Steffen via internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b25f5c058fb7872f"
Subject: Re: [PHP-DEV] P++: FAQ
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000b25f5c058fb7872f
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 9, 2019 at 7:08 PM Larry Garfield <larry@garfieldtech.com>
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.
> >
> > However, based on a lot of the feedback, both on internals@ and
> elsewhere -
> > it seems that a lot of people simply didn't really understand what this
> > idea was actually proposing to do.  I'll take the blame for that - by not
> > making the idea sufficiently clear.
> >
> > I went on and create an FAQ, that attempts to address many of the
> questions
> > and common misconceptions that repeatedly came up.
> >
> > It's available here:  https://wiki.php.net/pplusplus/faq
> >
> > Before you read it, I want to stress that this is an attempt to
> > provide *everyone
> > with a good deal, and nobody with a raw deal.  *It doesn't mean it's
> > successful at that (although I think it is) - but the motivation is clean
> > and positive.  If & when you read this FAQ, please try to read it without
> > any preconceived notions.
> >
> > If there are additional questions that you think are missing, please let
> me
> > know - or better yet, if you're up for constructively adding them - go
> > ahead and do that.
> >
> > Thanks,
> >
> > Zeev
>
>
> Zeev,
>
> First off, I want to be clear that I appreciate your efforts at
> conciliation here, and firmly believe your intent is benevolent.
>
> However, I ask you to consider that, intent or not, it's really easy for
> this proposal and some of your comments to come off as "strict people, go
> away and have your own corner".  That is likely not helping the discussion.
>
> Arvids Godjuks has already covered in great deal most of my issues with
> this proposal.  There's a few key additional points I want to bring up,
> though.
>
> First, as Sara observed I feel like this is conflating a number of
> different threads into a single binary question.
>
> There are "cleanup" type issues, such as short open tags, strpos() return
> values, strict comparisons, and so forth.  The main concern here is BC.  I
> suspect that, were we only concerned with greenfield projects and nothing
> else, these would be entirely uncontroversial and most people would be fine
> with them.  The main difference of opinion here isn't "how should the
> language evolve" but "how do we balance BC concerns with fixing design
> flaws, mostly from PHP's early days"?
>
> I don't think anyone can reasonably argue that strpos() returning false
> for not-found, which == 0,  is a good design; but "it's not bad enough
> design to justify breaking a billion lines of code" is a strong argument,
> and one on which reasonable people can reasonably disagree.  (And on which
> we can, and should, explore creative alternative approaches to "just break
> it".)
>
> Then there's an entirely different class of question regarding future
> additions.  Should PHP support union types, for instance.  That change has
> *no BC implications whatsoever*.  If PHP added union types, existing code
> would continue to run perfectly fine with no issue whatsoever.  New code
> that used union types wouldn't run on old PHP versions, naturally, but
> that's expected and is still not a BC issue.  The argument here is entirely
> different: "Great, one more thing I have to learn because someone is going
> to use it and I have to read it" vs. "This saves me so much time writing
> and debugging code, yay".  Again, reasonable people can reasonably disagree
> here.
>
> These are two almost entirely separate and orthogonal questions.  There's
> a few places where they touch -- mostly around bugs that are bugs only
> because of type juggling logic being non-intuitive at times -- but from a
> philosophical point of view they have nothing to do with each other.  Your
> proposal conflates them unnecessarily, and I think that's a crucial flaw in
> it.
>
> For example, suppose PHP++ mode gets union types, and has strpos() changed
> to return something safer, and has short-tags removed, while PHP-oldschool
> does not.  If I want to use union types... I still have to make just as
> many changes to my code, including potentially cleaning up 10000 instances
> of strpos() in my huge legacy codebase just so that I can use a union type
> in new code.  I have gained... extremely little here.  Coupling those two
> changes has not created any benefit, just more confusion and annoyance.
>
> Exactly. I think this is what I worry about the most with this. I'm
against removing short tags. I don't use type hints myself, but, I have no
problem with the fact they exist. If strict typing were introduced for
declared variables, I would almost definitely never use them - but I don't
mind them getting added. There is SO much that can be added and done to
evolve and improve PHP that doesn't introduce BC breaks. There are also
many things that will cause BC breaks that people will understand and
accept given the positive benefit. I keep feeling like this is all coming
as a result of the people treating the opposition to short tag removal as
being against BC breaks in general.


> What about common packages, or interfaces from FIG?  If FIG puts out an
> interface spec that makes use of a union type (for reasons that are
> completely reasonable in context), it's essentially forcing people to use
> PHP++ in order to use that spec; PHP-oldschool people are SOL.  Conversely,
> in order to maintain compatibility with PHP-oldschool FIG would have to
> eschew any features not in both branches; essentially not being able to use
> language features that are especially valuable for exactly that type of use
> case!
>
> Second point, suppose such a dual-mode happens.  Fast forward 2 years, and
> I find someone to bribe to help me revive the comprehensions proposal
> (which has no type considerations, necessarily).  Does that go into PHP++
> or PHP-oldschool or both?
>
> Essentially, every syntax-affected RFC would have an extra fight over
> which PHP flavors get it.  That doesn't seem like a polite thing to do to
> future generations of core contributors, including future-us.
>
> The only way to short circuit that would be to declare that PHP-oldschool
> never gets syntax changes at all, only PHP++ does.  Which would be a very
> strong signal that, yeah, PHP-oldschool is a dead language and anyone who
> isn't WordPress should just switch to PHP++ and be done with it.  But since
> your FAQ specifically mentions async as something that would be included in
> both modes I assume you're not proposing that PHP-oldschool be frozen in
> time syntactically, which means this debate would resurface for every RFC.
> That's a net loss for all involved.
>
> Finally, Zeev, you mention the "PHP philosophy" of being a dynamic
> language.  While that may well be your philosophy, and you have every right
> to have it, that has not been the "PHP philosophy" for years, as seen by
> all of the type "stuff" that's been successfully added to the language and
> gone into widespread use.  PHP doesn't have a coherent philosophy.  It is
> proudly directionless, steered by whoever happens to be writing code this
> week.  A few years back, Anthony Ferrara proposed developing an actual PHP
> mission statement to help resolve such debates over direction and was
> resoundingly rejected.  Rightly or wrongly, to speak of "PHP philosophy" as
> a thing one can actually reference is simply not possible.
>
> To end on a positive note, while I agree that there is often a tension on
> such questions I think PHP has been remarkable in how well it's navigated
> it.  I don't know any other language that has managed to evolve as much as
> PHP has from 5.3 onward with so little relative BC breakage.  The
> new-features/breakage ratio for modern-era PHP is, I think, bloody amazing.
>
> And when there has been good-reason breakage, we've rolled with it.  PHP
> 7.0's change to variable evaluation order was, on paper, a massive parser
> change... and yet the community rolled with it and upgraded and no one
> died.  It was a BC break, but a good one, and managed well, and it all
> worked out.
>
> On the typing front, the course PHP has been going down in practice is to
> have an increasingly robust type system, all of which is opt-in.  Frankly I
> think that's *super cool*, and a great way of balancing the prototyping
> benefits of dynamic languages (which are most seen at small scale
> codebases) and the robustness/safety of more refined type system (which are
> most seen in larger code bases) within a single ecosystem.  If a given
> codebase tends toward one or the other, it does so for a reason.  Most tend
> toward typed these days, for a reason, but also have places where they
> don't where it doesn't make sense to.
>
> That's a balancing act, yes.  It's not always an easy balancing act.  But
> frankly, I'd rather celebrate how well we've been able to pull it off over
> the years than lament how hard it is or introduce even more complexity and
> inconsistency in an attempt to not have to bother.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepeeler@gmail.com

--000000000000b25f5c058fb7872f--