Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52214
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=HJ2yqKNdO3sYsMUu1f6zAjXTgngwOP1dbiRH3o2pb2qyvrCPPzZr+/963IN9rxY5rL
         N9tlBnLAXLKtaq01BDR4wsYVWzxT8WdxEsEidjo4MNiS70vpqJst0gOcb+LW2Vves+Lx
         mKPynzjxqBsFTza49E0JHhJZDP9XHluKCrEAM=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <BANLkTim2KvLz=wAxvZiFqNhke0Ed6V5oBg@mail.gmail.com>
References: <4DC729EE.9090600@sugarcrm.com>
	<4DC75FFF.40008@lerdorf.com>
	<4DC7A7F0.4000504@sugarcrm.com>
	<BANLkTinn3+MCrSd7BAJCU03FMkuRAeydvA@mail.gmail.com>
	<4DC819D0.5010008@lerdorf.com>
	<BANLkTimn9teRbkAYxGcGCz9djDsvPY+WfQ@mail.gmail.com>
	<3680807C-229A-4889-9181-8953303425EC@stefan-marr.de>
	<4DC9081C.3020808@php.net>
	<BANLkTikM9uGybV=6=Lq=nZS1M62PjZJMqg@mail.gmail.com>
	<BANLkTim2KvLz=wAxvZiFqNhke0Ed6V5oBg@mail.gmail.com>
Date: Tue, 10 May 2011 15:13:32 +0200
Message-ID: <BANLkTimZbg=sxmvHdFYWM0NYwmfPp+JKOg@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001636e1ec5b12297704a2ebb941
Subject: Re: [PHP-DEV] 5.4 again
From: info@tyrael.hu (Ferenc Kovacs)

--001636e1ec5b12297704a2ebb941
Content-Type: text/plain; charset=UTF-8

On Tue, May 10, 2011 at 1:43 PM, Arvids Godjuks <arvids.godjuks@gmail.com>wrote:

> Hello Internals!
>
> Here is a point of view from an active user land developer on PHP
> development and feature requests and the politics going on in
> internals.
>
> Right now I think PHP has reached a milestone, where it is a need to
> take a break from large feature developing, witch takes a lot of time
> and effort, and do the cleanup stuff - bugs, accepted and unfinished
> features, make enhancement on existing stuff and clean up the code.
> New features should still come in, but the focus really should be to
> make a cleanup. I have observed over 3-4 years now some good RFC's
> that had been just forgotten, despite the fact that they were welcomed
> and work has been done. For example:
>
> The Tainted Variable RFC - https://wiki.php.net/rfc/taint - personally
> I would prefer that feature right now over any new feature, because it
> gives the ability to check for insecure variable handling and make
> sure you don't miss something. A major security enhancement on the
> language level (how the people can and will abuse it is not the issue
> - people do SQL selects in loops - tainted variable abuse is just
> negligent compared to that one) - isn't it worth the effort to finish
> that and release?
>

http://marc.info/?l=php-internals&m=129009775610865&w=2
<http://marc.info/?l=php-internals&m=129009775610865&w=2>

>
> The Lemon parser - https://wiki.php.net/rfc/lemon - I remember a lot
> of discussions on that and work being done and people wanting to do
> it. What happened?
>
>
http://marc.info/?l=php-internals&m=128872242418092&w=2
and as a bonus:
http://marc.info/?l=php-internals&m=128864465522116&w=2


> Error handling RFC's - https://wiki.php.net/rfc/error-optimizations
> and https://wiki.php.net/rfc/enhanced_error_handling - it's sitting
> there for quite some time. Any thought on that? Because error handling
> improvements will benifit all PHP developers - every single PHP
> developer out there in the wild.
>
> http://marc.info/?l=php-internals&m=126218949715825&w=2


> PHP Native Interface - https://wiki.php.net/rfc/php_native_interface -
> sounds and looks like a good and important project.
>

yeah, but AFAIK it wasn't finished, and by the comments I'm not entirely
sure that it's possible or viable at all.
http://marc.info/?l=php-internals&m=123901102014697&w=2


>
> And I even will not touch the topic of type hints and return type
> hints. At least param type hinting should be dealt with and done
> something about it, because right now it's at a half-completed state -
> only arrays and objects are supported.
>

that's a touchy subject.


>
> And probably the RFC wiki should be looked at and sorted out - there
> are some things implemented and rejected, witch haven't been moved to
> proper sections.
>
>
+1


>
> Said all that - I think annotations should be dropped for 5.4 for now
> and the development and refining continued until it's properly
> scrutinized, tested and ironed out. Right now to focus on delivering
> stuff that's all ready done or near completed (performance
> improvements for example) and look at the backlog and bugs.
>
>
"One of things I love most about working with Open Source Software like PHP
is the freedom. If I have an itch, I scratch it! If I want to work on new
features or document all the kinks and quirks of PHP, I can. We have the
freedom to work on exactly the things we care about and want to do."

so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.

and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.

ps:
"Right now I think PHP has reached a milestone, where it is a need to
take a break from large feature developing"
your suggestions also contains really large features.
I would add the unicode and LFS support for that list.
they are both long requested features, and nothing really happening to solve
those.

Tyrael

--001636e1ec5b12297704a2ebb941--