Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59892
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
Date: Fri, 13 Apr 2012 14:14:03 -0400
Message-ID: <CAGovj_P5pDK-zcv-GyGVzMsLHhS0QTmVNrTmOePwORhqAs0ahg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] A possible defining characteristic of PHP 6 ( was [off]
 PHP: a fractal of bad design )
From: dmgx.michael@gmail.com (Michael Morris)

On Wed, Apr 11, 2012 at 11:19 AM, Luke Scott <luke@cywh.com> wrote:
> I do agree with a lot of what was being said. But what can you do?

It would not be easy.  I lack the skills required.  And those who have
the skills lack the monumental time required.  But PHP could do what
Adobe did with Actionscript.  But it would not be easy or painless. It
probably isn't worth it.  But the tools are in place and there are RFC
ideas out there that, taken together might accomplish a fix.  But to
what end?

The idea I thought of a long time ago when AS3 came out was to do much
the same with PHP.  PHP 6 would ship with a legacy mode.  In that mode
all the existing functions would exist on the root namespace.  Turn it
off though and those functions disappear and get moved to \Legacy.
What actually remains is a remapped function library, perhaps taking
advantages of the autoboxing RFC to "fake" primitives as objects and
allow the sort of chaining we see in JavaScript.  Not every possible
function would be present in this model - libraries such as mysql,
mysqli or pdo would be imported into scope.

But this wouldn't be easy, and I don't think the willpower exists to
do it. This is after all a volunteer effort, and there are some things
that are simply out of the scope of such efforts.

PHP's goal has always been KISS, but the decisions over the last few
years run contrary to that.  Most onerous is, where Javascript, Java
and C have one scope resolution operator - a period - PHP has three
(->, \, :: ).  The only possible backwards compat fix to that is to
set up PHP 6 to not give a rat's ass about which of the three you use.
 That would restore simplicity, and two of the operators would die off
(my money is on :: and \ dying) in common use.  The engine
implications of that change are likely staggering.  This isn't the
only structural issue that needs to be addressed either.  Taken
together they are significant.

As to the original post that started this - it is what it is, a
blogger wanting attention, stating the obvious and trying to look
smart.  I'm singularly unimpressed and reading the other responses I'm
not alone.

It would help to have a conversation about what we want the next major
to be like before starting any work on it.  Otherwise it will just be
another evolution when what PHP really could use is a revolution the
likes of which hasn't been seen since PHP 3 came out.  But that
conversation itself will take time and the scope of what must be done
must truly be daunting.

> These are mostly quirks of the language. You learn to live with them.
> I don't make excuses for it. It is what it is.
>
> The only thing that infuriates me is the ternary operator being left
> associative. I want that fixed - screw bc on that one! I have been
> programming for 10 years and that one still confuses me! Most people
> just add parentheses to "fix" the problem. I wish someone would write
> an RFC to change this to right associative like every other language!
> *hint hint*
>
> Luke Scott
>
> On Apr 10, 2012, at 9:21 AM, Adir Kuhn <adirkuhn@gmail.com> wrote:
>
>> Hi folks,
>>
>> today I read this post, I think that some points are valid, follow the link for
>> you guys
>>
>> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>>
>> Adir Kuhn
>> ZCE - Zend Certified Engineer **PHP 5.3 #ZEND004035
>> PSMI - Professional Scrum Master I
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>