if you would drop zend engine as is and the idea behind it (which is most
difficult thing to admit and accept),
then use llvm-core. Making:
-- lexer, parser grammar
-- reference counting
-- type hint policies
-- builtins container
-- JITTER for compatibility.
-- bytecode
-- LLVM bytecode
-- symbolicated machine code
-- and so on

it's like picking your nose; meaning easy-peasy: when you have that in
place creating an other
dialect and 10000 of them will be same; or even experimenting new

it  will benefit the language at all:
- runtime execution, memory, exception handler  (`normally` handled)
- extension ecosystem you could autopen biddings without introducing bugs
from people.


On Fri, Aug 16, 2019 at 10:38 AM Mark Randall <mar...@gmail.com> wrote:

> On 16/08/2019 17:40, Chase Peeler wrote
> > A BC break to clean up the language might be justified in one case, and
> not
> > in another. To make a blanket statement that we will or will not attempt
> to
> > clean up the language is not wise in my opinion. It puts the project in a
> > bad place if it's forced to stick to it's decision, or, it makes the
> whole
> > reason for having made a decision pointless if we keep finding certain
> > items that are exceptions.
> Re: Entertainment, I'd liken it to something like watching the replay of
> a car crash. One really shouldn't, but one can't help but be mesmerised.
> Onto the matter of nuance in decisions, I agree that things should be
> done on a case-by-case basis, however, you have to have something to
> weigh the pros and cons against.
> Right now, so far as I can tell, the value of cleanup and improvement in
> any particular decision is undefined, because there's no general
> consensus on it.
> Take short open tags, there are cases made for and against, and in my
> opinion the strongest case for it is language cleanup, to have one fixed
> way of doing something that can be taught so future developers don't
> start wondering what the difference is between them.
> But what base weight does cleanup have? Is cleanup hugely important, or
> a complete non-factor that shouldn't be considered at all? If it's
> somewhere in between, where in between.
> It would never be used in absolute terms, it's always something that
> would strengthen or weaken other arguments. BC breaking cleanup for
> cleanups sake isn't really going to fly, but cleanup because a
> particular set of functions are inconsistent, or exhibit unintuitive
> behaviour, those ultimately all have to start with a consensus on if
> it's worth breaking something, or making something more complex
> (namespaced function aliases?) for the sake of making the language as a
> whole "better".
> My worry is that those with voting privileges on internals may end up
> splitting into two camps, and voting ideas up or down based on personal
> bias towards or against an underlying principle of clean-up and
> improvement or BC-supreme.
> I doubt it will come up _often_, but when it does, it seems to be
> incredibly disruptive. I would argue it needs a wider debate and then
> people should use the result of that debate to inform their voting,
> knowing that "PHP" has agreed to weigh certain general concepts in a
> particular way.
> Mark Randall
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to