Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106639
MIME-Version: 1.0
References: <alpine.DEB.2.21.1908141608160.29731@singlemalt.home.derickrethans.nl>
 <CAAfnsFX_z3oyJ6-sj7K9+LR690cCOAXoy0x7MtWqb6eUrFQThw@mail.gmail.com>
 <6534c240-e721-d5c1-a98c-86dfb9189b00@gmx.de> <5d56d50a.1c69fb81.26bc6.e2cdSMTPIN_ADDED_MISSING@mx.google.com>
 <CAPKYkKzesU4Dr8EFDUepvxBKau5jjzc9pMVr9zeaXET2LKgV=g@mail.gmail.com> <5d56ea18.1c69fb81.b7f4f.40aaSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5d56ea18.1c69fb81.b7f4f.40aaSMTPIN_ADDED_MISSING@mx.google.com>
Date: Fri, 16 Aug 2019 14:10:09 -0700
Message-ID: <CAHN63oPp3ZoL-7rEFF5UDtUavOSPpheiVmeKnujWgOHVr1HR_Q@mail.gmail.com>
To: Mark Randall <markyr@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f4e8bb0590426aa9"
Subject: Re: [PHP-DEV] Vote: Straw poll for P++ feasibility
From: mo.mu.wss@gmail.com ("M. W. Moe")

--000000000000f4e8bb0590426aa9
Content-Type: text/plain; charset="UTF-8"

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 <markyr@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
>
>

--000000000000f4e8bb0590426aa9--