On Thu, Aug 15, 2019, 3:20 AM Olumide Samson <hisamson...@gmail.com> wrote:
> On Thu, Aug 15, 2019, 10:52 AM Peter Kokot <peterko...@gmail.com> wrote: > > > On Wed, 14 Aug 2019 at 22:41, Zeev Suraski <z...@php.net> wrote: > > > > > > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans <der...@php.net> wrote: > > > > > > > Hi, > > > > > > > > In the last week(s) there has been a lot of chat about Zeev's P++ > idea. > > > > Before we end up spending this project's time and energy to explore > > this > > > > idea further, I thought it'd be wise to see if there is enough animo > > for > > > > this. Hence, I've created a document in the wiki as a poll: > > > > > > > > > > All, > > > > > > Using a humoristic tone, I'm happy that finally internals@ is so > > unified. > > > I almost get the feeling that you may not like the idea... > > > > > > On a more serious note, I'll keep the feedback on the validity of this > > vote > > > in just about every aspect (process, jurisdiction, anything really) to > > > myself, and say just two things: > > > > > > - The P++ idea makes absolutely no sense in vacuum. The reception > around > > > this idea implied a decision between 'one big happy family' and 'a > > split'. > > > Since at this stage these are the perceived choices - I'd vote against > it > > > too (which I just did, why not). However, I believe it's a false > choice. > > > > > > - It will absolutely make sense to discuss it when it'll start becoming > > > clearer to everyone that 'one big happy family' is really not an > option. > > > We'd be choosing how to soft split the family - granularly (2^n > > dialects), > > > into many editions (n dialects), or into two separate dialects with > > clearer > > > mandates (2 dialects). I get it that it's intangible for many of us > > > (myself included, to a degree), which is why this idea is perceived as > > the > > > 'evil splitter' for everyone to unite and rally against. Maybe I'm > > wrong, > > > and the changes/features that I think are about to make it into PHP > > aren't > > > going to require any sort of split. If that's the case - it's indeed a > > > horrible idea. We'd only be able to see that a but further down the > > road. > > > It's definitely too early to spend that level of energy on it at this > > stage > > > - but at the same time, it will definitely make sense to explore it if > & > > > when the reality I think we're going to be facing would begin to > unfold. > > > > > > I will not be responding to any further emails on this thread; I'll > > > happily reply to private messages though. > > > > > > Thanks, > > > > > > Zeev > > > > Hello @everyone, > > > > this then also means that PHP will now never be a consistent language > > and short tags will be forever in so we will all be able to support > > Chase's gigantic legacy project forever? > > > > Solution would be if we can make this issue that was mentioned: > > - elephpant vs elep++ant > > > > into a similar issue as is now: > > - elephpant vs elephpantwithstricttypes > > (non existent issue - all part of the one PHP itself) > > > > Zeev(Or anyone with such energy) can take up the game with same energy > he(Zeev) took the *elep++ant *up and I bet everyone (or the majority) would > really love the newer idea(elephpant vs elephpantwithstricttypes) and > probably take it up as a non issue coz it is all in the same part of the > one PHP itself(which already have its niche and brand). > > And, IMHO the strict type or cleaner version of PHP would improve many > sections of the language and even help with future implementations(maybe > sooner we might even implement more evolved and consistent aliases of > current C styled function naming) all of these and more in the same PHP > we've known. > > Or perhaps, an idea is to take a break on new implementations and make some > great changes which will pave way for great ideas and innovations. > > All of this are good ideas internals@ should be debating, I guess. > Current vote is 39 - 0 in favor of rejection. Who would've guessed this discussion would wind up being an exercise in unity lol....
