Hello, 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 features... 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. Best. 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 > >
