Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52222
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=ngtkSeFm3Fj9mpz/DjOjpKcrdABHDPfb1CP7fQaW9cLRIQDwTfsRHouyFkl59c5MSE
         wkEygr5Ebi7iVpBByomGY03jiXn2cGBP+PUDhSkGiNepH1iYJ+bdrWF41NzJ0w1AVBBc
         3ob+JmSRlwhXD7d9PKBQVNlLsRb8xXtPnd+/I=
MIME-Version: 1.0
In-Reply-To: <BANLkTimZbg=sxmvHdFYWM0NYwmfPp+JKOg@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>
	<BANLkTimZbg=sxmvHdFYWM0NYwmfPp+JKOg@mail.gmail.com>
Date: Tue, 10 May 2011 18:07:30 +0300
Message-ID: <BANLkTinOtUAZ8ZkzJ+ZiRm-dwQwLGLhMdA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] 5.4 again
From: arvids.godjuks@gmail.com (Arvids Godjuks)

2011/5/10 Ferenc Kovacs <info@tyrael.hu>:
>
>
>>
>> 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=3Dphp-internals&m=3D129009775610865&w=3D2
>

Well, there is the impact, but seriously, do that many people will use
it in production? I certainly will not, but on the DEV and on my local
development machine it will be enabled period.

>>
>> 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=3Dphp-internals&m=3D128872242418092&w=3D2
> and as a bonus:
> http://marc.info/?l=3Dphp-internals&m=3D128864465522116&w=3D2
>

The thing here is that there seems to be no movement at all. As I
remember, there just has to be work done to write the grammar parser
in Lemon in a such way, that it is fast enough and would have range
for improvements. Right now it seems that no one is even trying.

>>
>> 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=3Dphp-internals&m=3D126218949715825&w=3D2
>
Yep, bad suggestion from my side :)

>>
>> 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=3Dphp-internals&m=3D123901102014697&w=3D2
>
It was more like an example of abandoned projects witch stay on RFC
page for long time and make an impression that it will be dealt with.
Just move it to "Not accepted/Abbandoned" category then.
>>
>> 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.
>
Indeed it is. But at least the param type hinting should be finished,
cause it's all ready half there.

>>
>> 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 P=
HP
> 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 differ=
ent
> priorities and expectations about the PHP language than the core devs.
> to make things worse, they cannot write patches for the core, and the cor=
e
> devs rarely work on something which they don't=C2=A0particularly=C2=A0nee=
d or like.
> and I think that the only option where we can change that, is that us, th=
e
> php userland devs has to be more active on the mailing lists, irc, bug
> tracking, writing RFCs etc.
Yes, it is the problem. And usually the userland developer voices are
just overflown by other people - core devs and people who invest in
developing their own stuff. Maybe core devs could somehow highlight
the things that userland developers are writing?

> 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 so=
lve
> those.
>
> Tyrael
That was the intent of my e-mail in the first place - to show that
there is a ton of stuff that is in questionable state, half done or
most of the problems solved and it just needs some love to become
production ready. There has to be a re-focus for some time. PHP
5.2-5.3 where a good example of cleaning up, speeding up and very good
feature development - anonymous functions for example are just
freaking awesome stuff.

It is a good idea to look at all the big stuff that is just begging to
be fixed/added/done - Unicode is really the pain in the ass
(especially for me, because I have to work with multi-language
websites and systems - Russian, Latvian, English, Arabic and other).
There just has to be some sort of core developer decision to stop
actively developing new features and just clean up the backlog.
Community probably will follow with that too.