subject:"\[PHP\-DEV\] 5.4 again"


Hi!


Stas, in the past we had alphas. Is there any reason why we wouldn't
roll one out asap? (revert the typehints stuff and go).



OK, I can do the stuff (typehints, branch, tag) on the weekend. I don't 
know how to roll the packages  do the mails though, so if somebody 
could volunteer there it'd be great :)


Some of the proposed changes though are not BC-safe, so we should warn 
people that this alpha is not the fixed API yet.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again


Hi!


Waiting a month or two longer is worth it, especially considering the
5.4 momentum feels real this time around. We're creating a real TODO,
and have a real tentative timeline, so forcing a premature alpha at
this point (thus closing off feature/api discussion) is a bad idea. A
big -1 here. I mean, we may as well get it right since we've waited
so long already.


I don't think it's closing feature discussion. We can have another alpha 
after the discussion, or more than one. I can see the value of having 
_something_ right now to signify we mean it this time, but that 
something would definitely not be anything near final and we can take 
features in after the discussion is done.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-11 Thread Johannes Schlüter

On Wed, 2011-05-11 at 11:43 -0700, Stas Malyshev wrote:
 Hi!
 
  Stas, in the past we had alphas. Is there any reason why we wouldn't
  roll one out asap? (revert the typehints stuff and go).
 
 
 OK, I can do the stuff (typehints, branch, tag) on the weekend. I don't 
 know how to roll the packages  do the mails though, so if somebody 
 could volunteer there it'd be great :)

Most parts (all?) is documented in README.RELEASE_PROCESS I can assist. 

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again


Hi!


Most parts (all?) is documented in README.RELEASE_PROCESS I can assist.


Thanks!
Interestingly enough, this file still refers to CVS in trunk. I guess 
somebody familiar with up-to-date process has to update it :)


--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again


Hi!


Most parts (all?) is documented in README.RELEASE_PROCESS I can assist.


Thanks!
Interestingly enough, this file still refers to CVS in trunk. I guess 
somebody familiar with up-to-date process has to update it :)


--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-11 Thread Sebastian Bergmann


On 05/11/2011 08:20 PM, Johannes Schlüter wrote:

+1


 +1

--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-11 Thread Philip Olson


On May 11, 2011, at 12:50 PM, Stas Malyshev wrote:

 Hi!
 
 Waiting a month or two longer is worth it, especially considering the
 5.4 momentum feels real this time around. We're creating a real TODO,
 and have a real tentative timeline, so forcing a premature alpha at
 this point (thus closing off feature/api discussion) is a bad idea. A
 big -1 here. I mean, we may as well get it right since we've waited
 so long already.
 
 I don't think it's closing feature discussion. We can have another alpha 
 after the discussion, or more than one. I can see the value of having 
 _something_ right now to signify we mean it this time, but that something 
 would definitely not be anything near final and we can take features in after 
 the discussion is done.

The alpha release proposal by Andi contains the text:

  I think we (almost) all agree that we need to start pushing PHP 5.4 with all 
the goodness that has been developed to-date. Additional features can wait 
for the next version.

So, that's the concern there. But if the alpha is simply a trick to convince 
people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do 
it. ;)

Regards,
Philip


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-11 Thread Rasmus Lerdorf


On 05/11/2011 02:10 PM, Philip Olson wrote:


So, that's the concern there. But if the alpha is simply a trick to convince 
people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do 
it. ;)


There are still quite a few test failures in trunk. Some of them are 
also in the 5_3 branch. In some cases the tests are simply bad. In a few 
the test case contains binary data that got mangled in the move to 
Subversion. It would be nice if just 1 in 10 people reading the list 
here would grab both trunk and 5_3 and run make test in each tree and 
then fix at least 1 test each. We would have no test failures by the end 
of the day other than a few tricky ones. If an alpha release will 
encourage this, great. If we could get people to just do it on their own 
without the alpha, even better.


And yes, I know the tests take forever to run. Get yourself a fast 
machine with an SSD, and remember you can run partial tests using:


  make test TESTS=ext/hash

for example to just run the tests for the hash extension.

Also, when a test fails, cd into the ext/hash/tests directory and you 
will see .out, .exp, .diff and .php files for the failed test. That is, 
the output, the expected output, the diff between them and the php 
script itself extracted from the .phpt file containing the failed test case.


And if you can't figure out how to fix a test, post the details here. 
I'd love to point some of the obvious talents and energy of this list 
towards the code. If you don't have an svn account for committing your 
fixed test, go to http://www.php.net/svn-php.php and fill in the little 
form at the bottom there and put in the test that you fixed and a 
1-liner about how you fixed it and I will set you up with an account 
right away. Info on how to check out the code from svn is here:

https://wiki.php.net/vcs/svnfaq

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-11 Thread Stefan Marr

Hi:


On 11 May 2011, at 23:10, Philip Olson wrote:

 On May 11, 2011, at 12:50 PM, Stas Malyshev wrote:
 The alpha release proposal by Andi contains the text:
 
  I think we (almost) all agree that we need to start pushing PHP 5.4 with 
 all the goodness that has been developed to-date. Additional features can 
 wait for the next version.
 
 So, that's the concern there. But if the alpha is simply a trick to convince 
 people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do 
 it. ;)
+1 that would definitely demonstrate the ability to get moving again.
An important sign to the larger community.
However, the stability/instability of the feature set should be clearly defined.

Thanks
Stefan


-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-11 Thread Philip Olson


On May 11, 2011, at 3:56 PM, Rasmus Lerdorf wrote:

 On 05/11/2011 02:10 PM, Philip Olson wrote:
 
 So, that's the concern there. But if the alpha is simply a trick to convince 
 people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then 
 do it. ;)
 
 There are still quite a few test failures in trunk. Some of them are also in 
 the 5_3 branch. In some cases the tests are simply bad. In a few the test 
 case contains binary data that got mangled in the move to Subversion. It 
 would be nice if just 1 in 10 people reading the list here would grab both 
 trunk and 5_3 and run make test in each tree and then fix at least 1 test 
 each. We would have no test failures by the end of the day other than a few 
 tricky ones. If an alpha release will encourage this, great. If we could get 
 people to just do it on their own without the alpha, even better.
 
 And yes, I know the tests take forever to run. Get yourself a fast machine 
 with an SSD, and remember you can run partial tests using:
 
  make test TESTS=ext/hash
 
 for example to just run the tests for the hash extension.
 
 Also, when a test fails, cd into the ext/hash/tests directory and you will 
 see .out, .exp, .diff and .php files for the failed test. That is, the 
 output, the expected output, the diff between them and the php script itself 
 extracted from the .phpt file containing the failed test case.
 
 And if you can't figure out how to fix a test, post the details here. I'd 
 love to point some of the obvious talents and energy of this list towards the 
 code. If you don't have an svn account for committing your fixed test, go to 
 http://www.php.net/svn-php.php and fill in the little form at the bottom 
 there and put in the test that you fixed and a 1-liner about how you fixed it 
 and I will set you up with an account right away. Info on how to check out 
 the code from svn is here:
 https://wiki.php.net/vcs/svnfaq

This is a great challenge. Long ago I decided that failed tests are expected in 
PHP, because out of the ~100 or so times I've run it these past n years, it has 
always (afair) failed. Changing this fact by having it pass would change 
peoples (at least my) perception that running 'make test' is a waste of time, 
as is (was) looking into why they failed. For example, just now trunk gives me 
55 failed tests and 17 expected fails with a vanilla build.

We once had a matrix showing test results per setup (OS, phpversion, per 
configure switches) but it was someones pet project and the code has long since 
been lost (he looked years ago). Maybe such a beast would be useful.

Also, how about we change[1] it so php.qa.reports[2] stops receiving 5_2 
results, and always receives snapshot results? For example, snapshot test 
results (5_3 and trunk) are configured to _not_ go there today.

Regards,
Philip

[1] http://svn.php.net/viewvc/web/qa/trunk/include/release-qa.php
[2] http://news.php.net/php.qa.reports



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again


Hi!


We once had a matrix showing test results per setup (OS, phpversion,
per configure switches) but it was someones pet project and the code
has long since been lost (he looked years ago). Maybe such a beast
would be useful.


We can do a table saying which tests fails where in the wiki right now...


Also, how about we change[1] it so php.qa.reports[2] stops receiving
5_2 results, and always receives snapshot results? For example,
snapshot test results (5_3 and trunk) are configured to _not_ go
there today.


I think it's an excellent idea. 5.2 is not going to be fixed anyway, we 
need 5.3 and trunk much more.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Sebastian Bergmann

Am 09.05.2011 18:55, schrieb Marcelo Gornstein:
 regarding the annotations stuff: it seems the php community (in
 general) really wants annotations. lots of important and widely used
 frameworks use them (meaning that not only the plain php users have a
 use for this feature, but also the users of the respective frameworks,
 increasing the overall user number interested). i.e: doctrine,
 symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.

 I see no problem with the way that PHPUnit handles its annotations at
 the moment. I do, however, see problems with a migration of PHPUnit to
 an annotation system provided by PHP: whatever its syntax, if I wanted
 to use it in PHPUnit that means that existing tests will have to be
 changed.

-- 
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

On Tue, May 10, 2011 at 11:35 AM, Sebastian Bergmann sebast...@php.netwrote:

 Am 09.05.2011 18:55, schrieb Marcelo Gornstein:
  regarding the annotations stuff: it seems the php community (in
  general) really wants annotations. lots of important and widely used
  frameworks use them (meaning that not only the plain php users have a
  use for this feature, but also the users of the respective frameworks,
  increasing the overall user number interested). i.e: doctrine,
  symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.

  I see no problem with the way that PHPUnit handles its annotations at
  the moment. I do, however, see problems with a migration of PHPUnit to
  an annotation system provided by PHP: whatever its syntax, if I wanted
  to use it in PHPUnit that means that existing tests will have to be
  changed.


why would you migrate if you are fine with your current setup?

Tyrael

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Sebastian Bergmann

Am 09.05.2011 21:33, schrieb Stefan Marr:
 That is how open source works.

 Traits is a perfect example, indeed: you came to the list with a clear
 specification of the feature as well as arguments for why you think the
 feature is useful. Moreover, you provided tests that reflected the
 specification and a patch that implemented the specification and
 satisfied the tests.

-- 
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

On Tue, May 10, 2011 at 11:40 AM, Sebastian Bergmann sebast...@php.netwrote:

 Am 09.05.2011 21:33, schrieb Stefan Marr:
  That is how open source works.

  Traits is a perfect example, indeed: you came to the list with a clear
  specification of the feature as well as arguments for why you think the
  feature is useful. Moreover, you provided tests that reflected the
  specification and a patch that implemented the specification and
  satisfied the tests.


how is it different from the annotations proposed by Guilherme and Pierrick?
the only difference that the traits got accepted and the annotations not
(yet), but they were both announced ~ the same time, both were backed up
with rfc, implementation and tests.
http://marc.info/?l=php-internalsm=128274106801222w=2
if you follow the topic, you will see that the same people brought up the
same arguments against adding traits than we can see about
annotations(comparing traits to include, annotations to docblocks,
performance problems, playing the bloated card, etc.), but they were
overwhelmed by the positive feedback and the buzz about what can be further
improved, etc.
it seems that annotations lacked the critical mass when it was proposed. :(

Tyrael

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Drak

On 10 May 2011 15:25, Sebastian Bergmann sebast...@php.net wrote:
 Am 09.05.2011 21:33, schrieb Stefan Marr:
 That is how open source works.

  Traits is a perfect example, indeed: you came to the list with a clear
  specification of the feature as well as arguments for why you think the
  feature is useful. Moreover, you provided tests that reflected the
  specification and a patch that implemented the specification and
  satisfied the tests.

That is the way to meet with the least resistance for sure, however,
it's better  to sound out the idea beforehand before you waste time on
something that might get stone-walled.  But, even a lone well
thought-out specification may be picked apart by group scrutinisation.
 Overall in OSS, the problem is if you don't sound out an idea first,
you might be wasting your time if it's stonewalled, but if you don't
immediately provide a specification and patch, you get resistance
because it's yet another feature request to an already overworked,
and over burdened core development team.  Contrasting, if you propose
something that is generally liked by the core development team, you
may not even have to write a patch for it to materialise.  Getting
something approved is therefore not so straightforward - you need some
luck and who's reading the list at the time...

Probably what is missing is some sort of crowd sourcing to really
gauge opinion on a wider basis.  Something like this
http://ideas.joomla.org makes it very clear what is important to the
wider community or not.

Regards,

Drak

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Stefan Marr


On 10 May 2011, at 12:04, Ferenc Kovacs wrote:
 performance problems, playing the bloated card, etc.), but they were
 overwhelmed by the positive feedback and the buzz about what can be further
 improved, etc.
 it seems that annotations lacked the critical mass when it was proposed. :(

From my perspective, getting Traits in was also a lot of hard work with respect 
to the community.
(Actually more then the technical details).
While there seemed to be quite some buzz in the general PHP world, internals 
was rather uninterested in the beginning.

The whole thing required a lot of, what I would characterize as, hand-holding.
Internals is not the most open community and needs not only good arguments, but 
persistence.
And, well, it also seem to require to get in touch with the right people...

And now the whole discussion about 5.4 goes again in a direction where it will 
probably be stalled in the end.
I am not to optimistic about an actual release date within 2011.

Best regards
Stefan


-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Arvids Godjuks

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?

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?

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.

PHP Native Interface - https://wiki.php.net/rfc/php_native_interface -
sounds and looks like a good and important project.

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.

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.


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.

Arvids.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

On Tue, May 10, 2011 at 1:43 PM, Arvids Godjuks arvids.godj...@gmail.comwrote:

 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-internalsm=129009775610865w=2
http://marc.info/?l=php-internalsm=129009775610865w=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-internalsm=128872242418092w=2
and as a bonus:
http://marc.info/?l=php-internalsm=128864465522116w=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-internalsm=126218949715825w=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-internalsm=123901102014697w=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

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread christian . kaps


On Tue, 10 May 2011 15:13:32 +0200, Ferenc Kovacs wrote:

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.



I'm a userland developer, reading the list since two years I think. And 
I must say I'm totally frustrated about the developing process itself.


The actual proposal process is always the same:

1. Someone proposes a new feature.
2. As next there is a long discussion about the topic which ends up 
with more dissent than consensus.

3. A long time nothing about the topic.
4. Start new from first point.

And I think in the near feature there will be no changes with the old 
structures.


Greetings
Christian

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Pas


Hi,

On 2011.05.10. 15:13, Ferenc Kovacs wrote:
 ...

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.



I have a feeling that even though PHP's users are happen to be 
developers, they won't do these. Or they might do, but they'd 
practically become core developers.


Open Source users want shiny web42.0 interfaces where they can 'upvote' 
ideas. And if every year the topmost idea would get implemented, they 
would be happy. (It's just how humans work, in my opinion.)


PHP users might file bugs. Might read RFCs when linked to. Occasionally 
read the mailing list to figure out What's cooking in Internals. But 
after seeing endless pages about get a perfect idea, write a patch, 
document it in an RFC, wait for SVN account, and maybe we'll look at it 
they aren't likely to jump in.


And even though some parts of the userbase is quite engaged ( 
https://github.com/symfony/symfony/pulls 
https://github.com/symfony/symfony/graphs/traffic - selection bias and 
whatnot ), there's still a very big barrier between writing a pull 
request on the off chance that some might incorporate it versus raging 
on internals for months.


So, it's just not going to happen.

Thus I don't find it surprising that framework/library developers are 
the ones hanging around and not the CompSci freshmen that stumbled upon 
a PHP tutorial.


Also, PHP being in fact very flexible and fast, and well documented, 
there aren't a lot of userland problems that would scream for immediate 
divine core developer intervention. So that's an other factor why 
there's little to no interaction with developers.


And when there are problems, they're usually very complex (unicode) or 
solving them would require virtually shifting the whole language 
(multi-threading support, from more opcode caching to pre-compiled 
binaries, long running persistent PHP apps to reduce class loading and 
other initialization penalty). It looks like for most uses of PHP other 
languages would be better suited, except they suck more for various 
reasons (Java - plain old and full of bloated frameworks; Scala - too 
much awesome packed into it results in a steep learning curve; ASP.NET - 
Windows only).


And I haven't mentioned Python, because it gets used, it's growing (and 
I suspect a lot of people are 'converting' to it):

http://www.go-hero.net/jam/11/languages



--
Pas



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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Alain Williams

On Tue, May 10, 2011 at 03:55:26PM +0200, christian.k...@mohiva.com wrote:

 I'm a userland developer, reading the list since two years I think. And 
 I must say I'm totally frustrated about the developing process itself.
 
 The actual proposal process is always the same:
 
 1. Someone proposes a new feature.
 2. As next there is a long discussion about the topic which ends up 
 with more dissent than consensus.

I think that part of the problem is that we come to the language from different
perspectives and so have different needs and use PHP in different ways.
PHP is a language that is used by a very wide variety of people, most of who
would never think of going anywhere near a mail list like this one.

This might mean that we have to accept that people will use PHP in ways that
many of us might seem wrong. There is little point in telling them that they
should be doing things differently because as far as they are concerned they
are doing just fine.

An example of this is the procedural/objects paradigm choice.
OO is probably better for large projects and is favoured by many on this list.
Many PHP users find objects and can probably use them, but almost certainly
won't be able to write objects - the programs that they are writing are fine
as procedural.

So: rather than saying ''OO is the only way'', we need to make life easier
for those who will never write OO code.

Balanced against that is that you can't put everything into PHP.


A couple features that I have have suggested and would like:

1) The ability to insist that variables are declared before use,
   aka perl's ''use strict''. To avoid breakages this would have to be
   on a module by module basis, the way of detecting this is to switch
   this on for the rest of a module if a declaration (outside of an object
   or function) is seen, eg:
  var $something;

   Why ? It will reduce problems of misspelled variable names.
   'var' is already a keyword so no problem there.

2) Namespaces to include variables - not just functions, objects  constants.
   The argument against this is to use objects, but see my comments above,
   objects are not for everyone.
   This would break every variable appearing in $GLOBAL - but for new code
   does this really matter ?

 3. A long time nothing about the topic.
 4. Start new from first point.
 
 And I think in the near feature there will be no changes with the old 
 structures.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Christian Kaps


On Tue, 10 May 2011 15:20:14 +0100, Alain Williams wrote:
On Tue, May 10, 2011 at 03:55:26PM +0200, christian.k...@mohiva.com 
wrote:


I'm a userland developer, reading the list since two years I think. 
And
I must say I'm totally frustrated about the developing process 
itself.


The actual proposal process is always the same:

1. Someone proposes a new feature.
2. As next there is a long discussion about the topic which ends up
with more dissent than consensus.


I think that part of the problem is that we come to the language from
different
perspectives and so have different needs and use PHP in different 
ways.
PHP is a language that is used by a very wide variety of people, most 
of who

would never think of going anywhere near a mail list like this one.

This might mean that we have to accept that people will use PHP in 
ways that
many of us might seem wrong. There is little point in telling them 
that they
should be doing things differently because as far as they are 
concerned they

are doing just fine.

An example of this is the procedural/objects paradigm choice.
OO is probably better for large projects and is favoured by many on
this list.
Many PHP users find objects and can probably use them, but almost 
certainly
won't be able to write objects - the programs that they are writing 
are fine

as procedural.

So: rather than saying ''OO is the only way'', we need to make life 
easier

for those who will never write OO code.

Balanced against that is that you can't put everything into PHP.




Yes, this is the point. In my opinion PHP has an identity problem. Is 
it an object oriented or a procedural language? I think the best from 
both worlds seems to be inoperative!



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Arvids Godjuks

2011/5/10 Ferenc Kovacs i...@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=php-internalsm=129009775610865w=2


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=php-internalsm=128872242418092w=2
 and as a bonus:
 http://marc.info/?l=php-internalsm=128864465522116w=2


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=php-internalsm=126218949715825w=2

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=php-internalsm=123901102014697w=2

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 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.
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 solve
 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

RE: [PHP-DEV] 5.4 again

2011-05-10 Thread Jonathan Bond-Caron

On Mon May 9 07:29 PM, guilhermebla...@gmail.com wrote:
 Hi Andi,
 
 Sorry, but I mentioned on other thread that RFC is outdated.
 I just finished an update to it bringing to recent implementation. The 
 idea is to get the big picture here, I may have left from previous 
 RFC, but if I did that, please just point out and I can fix.
 This implementation is *way* simpler.
 
 Here is the direct link: https://wiki.php.net/rfc/annotations
 

As for positive feedback, it's a net improvement over the previous RFC and I 
like the simplifications.

Is there really a need for:
Array   ::= array( ArrayEntry {, ArrayEntry}* )

Do you have examples of where that's needed?



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Matthew Weier O'Phinney

On 2011-05-10, Ferenc Kovacs i...@tyrael.hu wrote:
 --0016e657b06a1ac32a04a2e91661
 Content-Type: text/plain; charset=UTF-8

 On Tue, May 10, 2011 at 11:40 AM, Sebastian Bergmann sebast...@php.net 
 wrote:

  Am 09.05.2011 21:33, schrieb Stefan Marr:
   That is how open source works.
 
   Traits is a perfect example, indeed: you came to the list with a clear
   specification of the feature as well as arguments for why you think the
   feature is useful. Moreover, you provided tests that reflected the
   specification and a patch that implemented the specification and
   satisfied the tests.
 

 how is it different from the annotations proposed by Guilherme and Pierrick?
 the only difference that the traits got accepted and the annotations not
 (yet), but they were both announced ~ the same time, both were backed up
 with rfc, implementation and tests.
 http://marc.info/?l=php-internalsm=128274106801222w=2
 if you follow the topic, you will see that the same people brought up the
 same arguments against adding traits than we can see about
 annotations(comparing traits to include, annotations to docblocks,
 performance problems, playing the bloated card, etc.), but they were
 overwhelmed by the positive feedback and the buzz about what can be further
 improved, etc.
 it seems that annotations lacked the critical mass when it was proposed. :(

Traits, to me, was a very different proposal. Why? Because there was no
way to emulate the functionality within the language already. 

With annotations, my main issue, which I voiced early (and others did as
well), is that we can already do much of what the RFC proposes by
parsing annotations in docblocks. In fact, adding the support
potentially creates more work for developers (more on that below).

I don't see a need for a new grammar and syntax; why don't we just
provide a standard for annotations within docblocks, and provide a
native parser for annotations that follow that format? This allows folks
who are already using docblock annotations a boost in speed, and only
gets invoked during reflection (since otherwise it's considered a
comment). 

Guilherme often raises ZF's server classes as poster children for why
annotations support is needed. However, I'd like to note that I don't
feel this way at all. In fact, annotations support would create _more_
work for us. Why? Because now we'd need both our docblock comments (in
order to generate the API docs) AND annotations (to provide the server
hinting we provide, which currently is derived from PHPDoc annotations).
A native docblock annotation parser would much better suit our purposes.

So, basically, we're in a situation where there's no consensus on
whether the feature is needed or what the approach should be, and people
pointing fingers at eachother indicating the other party is not
listening or providing constructive feedback. I think that's reason
enough to pan the feature for 5.4.

-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Lester Caine


Matthew Weier O'Phinney wrote:

Guilherme often raises ZF's server classes as poster children for why
annotations support is needed. However, I'd like to note that I don't
feel this way at all. In fact, annotations support would create_more_
work for us. Why? Because now we'd need both our docblock comments (in
order to generate the API docs) AND annotations (to provide the server
hinting we provide, which currently is derived from PHPDoc annotations).
A native docblock annotation parser would much better suit our purposes.


Thank you Matthew. That was the part of the 'problem' I was not getting across 
very well. The bulk of my existing code base has this documentation already, and 
phpeclipse simply picks it up and runs with it ...

including type hinting ...

--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Stas Malyshev


Hi!


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.


Everybody would be using that in production. Production is where the 
danger is, nobody would break into developer machine since nobody can 
access it except for developers!

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Zeev Suraski


On May 10, 2011, at 18:57, Matthew Weier O'Phinney weierophin...@php.net 
wrote:

 With annotations, my main issue, which I voiced early (and others did as
 well), is that we can already do much of what the RFC proposes by
 parsing annotations in docblocks. In fact, adding the support
 potentially creates more work for developers (more on that below).
 
 I don't see a need for a new grammar and syntax; why don't we just
 provide a standard for annotations within docblocks, and provide a
 native parser for annotations that follow that format? This allows folks
 who are already using docblock annotations a boost in speed, and only
 gets invoked during reflection (since otherwise it's considered a
 comment). 
 
 Guilherme often raises ZF's server classes as poster children for why
 annotations support is needed. However, I'd like to note that I don't
 feel this way at all. In fact, annotations support would create _more_
 work for us. Why? Because now we'd need both our docblock comments (in
 order to generate the API docs) AND annotations (to provide the server
 hinting we provide, which currently is derived from PHPDoc annotations).
 A native docblock annotation parser would much better suit our purposes.
 
 So, basically, we're in a situation where there's no consensus on
 whether the feature is needed or what the approach should be, and people
 pointing fingers at eachother indicating the other party is not
 listening or providing constructive feedback. I think that's reason
 enough to pan the feature for 5.4.

Couldn't have phrase it better, it illustrates the opinion I shared here a few 
months ago very well.

+1

Zeev


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Sebastian Bergmann

Am 10.05.2011 17:57, schrieb Matthew Weier O'Phinney:
 I think that's reason enough to pan the feature for 5.4.

 Agreed.

-- 
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Drak

On 10 May 2011 21:55, Lester Caine les...@lsces.co.uk wrote:
 Matthew Weier O'Phinney wrote:
 Thank you Matthew. That was the part of the 'problem' I was not getting
 across very well. The bulk of my existing code base has this documentation
 already, and phpeclipse simply picks it up and runs with it ...
 including type hinting ...

If PHP releases new syntax of course the IDE vendors will release
support pronto for it.

Drak

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Lester Caine


Drak wrote:

On 10 May 2011 21:55, Lester Caineles...@lsces.co.uk  wrote:

  Matthew Weier O'Phinney wrote:
  Thank you Matthew. That was the part of the 'problem' I was not getting
  across very well. The bulk of my existing code base has this documentation
  already, and phpeclipse simply picks it up and runs with it ...
  including type hinting ...

If PHP releases new syntax of course the IDE vendors will release
support pronto for it.


Which world do you live in? We have to find the time to DO all this extra work! 
Or are you only using commercial product?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] 5.4 again

2011-05-10 Thread Mike Robinson

May-10-11 11:57 AM Matthew Weier O'Phinney wrote: 

 A native docblock annotation parser would much better suit our
 purposes.

+1, FWIW.

 So, basically, we're in a situation where there's no consensus on
 whether the feature is needed or what the approach should be, and
 people pointing fingers at eachother indicating the other party is
 not listening or providing constructive feedback. I think that's
 reason enough to pan the feature for 5.4.

Humbly, I agree.

Best Regards,

Mike Robinson


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

On Tue, May 10, 2011 at 8:20 PM, Mike Robinson m...@rile.ca wrote:

 May-10-11 11:57 AM Matthew Weier O'Phinney wrote:

  A native docblock annotation parser would much better suit our
  purposes.

 +1, FWIW.


extending the Reflection::getDocComment to support retrieving the docblock
comment as an array of key = value pairs wouldn't be too hard to implement.
I find it funny that you, Sebastian and others who are supporting docblocks
over annotations  didn't found the time to do it, but you always bring this
up.

Tyrael

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Matthew Weier O'Phinney

On 2011-05-10, Ferenc Kovacs i...@tyrael.hu wrote:
 --bcaec51a7af89cba6304a2f01d01
 Content-Type: text/plain; charset=UTF-8

 On Tue, May 10, 2011 at 8:20 PM, Mike Robinson m...@rile.ca wrote:

  May-10-11 11:57 AM Matthew Weier O'Phinney wrote:
 
   A native docblock annotation parser would much better suit our
   purposes.
 
  +1, FWIW.
 
 
 extending the Reflection::getDocComment to support retrieving the docblock
 comment as an array of key = value pairs wouldn't be too hard to implement.
 I find it funny that you, Sebastian and others who are supporting docblocks
 over annotations  didn't found the time to do it, but you always bring this
 up.

We have in ZF -- Zend_Reflection extends the Reflection API to provide
this sort of feature (though admittedly the annotation, or tag support
as we called it, could use a little more rigor in matching). I
personally am not comfortable enough in my C skills to attempt it in the
Zend Engine.

-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread dukeofgaming



 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.


Why not open a Google Groups list?, having every message recorded publicly
and being easy to join-in I'd bet that the situation would change. I've seen
it work really well for other open source projects, such as Joomla and
Symfony.

Regards,

David Vega

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread guilhermebla...@gmail.com

Hi all,

Based on an extensive chat with Matthew, I think we reached some consensus.
I'll write another RFC related to Annotations in docblocks, then we
can chat until reach some standardization and availability.

Regards,

On Tue, May 10, 2011 at 4:28 PM, dukeofgaming dukeofgam...@gmail.com wrote:


 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.


 Why not open a Google Groups list?, having every message recorded publicly
 and being easy to join-in I'd bet that the situation would change. I've seen
 it work really well for other open source projects, such as Joomla and
 Symfony.

 Regards,

 David Vega




-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

On Tue, May 10, 2011 at 9:31 PM, guilhermebla...@gmail.com 
guilhermebla...@gmail.com wrote:

 Hi all,

 Based on an extensive chat with Matthew, I think we reached some consensus.
 I'll write another RFC related to Annotations in docblocks, then we
 can chat until reach some standardization and availability.

 Regards,


glad to hear that.

Tyrael

Re: [PHP-DEV] 5.4 again

On Tue, May 10, 2011 at 9:28 PM, dukeofgaming dukeofgam...@gmail.comwrote:


 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.


 Why not open a Google Groups list?, having every message recorded publicly
 and being easy to join-in I'd bet that the situation would change. I've seen
 it work really well for other open source projects, such as Joomla and
 Symfony.


you can already do that through http://marc.info/?l=php-internals or the
newsgroup, see http://php.net/mailing-lists.php
albeit google groups is better imho

Tyrael

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread dukeofgaming

On Tue, May 10, 2011 at 2:42 PM, Ferenc Kovacs i...@tyrael.hu wrote:



 On Tue, May 10, 2011 at 9:28 PM, dukeofgaming dukeofgam...@gmail.comwrote:


 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.


 Why not open a Google Groups list?, having every message recorded publicly
 and being easy to join-in I'd bet that the situation would change. I've seen
 it work really well for other open source projects, such as Joomla and
 Symfony.


 you can already do that through http://marc.info/?l=php-internals or the
 newsgroup, see http://php.net/mailing-lists.php
 albeit google groups is better imho

 Tyrael


Yeah, I forgot to mention that everything is threaded there, so its easier
to follow.

Regards,

David Vega

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread Johannes Schlüter

On Tue, 2011-05-10 at 20:27 +0200, Ferenc Kovacs wrote:
 I find it funny that you, Sebastian and others who are supporting docblocks
 over annotations  didn't found the time to do it, but you always bring this
 up.

http://pecl.php.net/package/docblock exists. I never used it, but either
it is completely unknown or doesn't bring benefits over a userspace
implementation (typical trade-offs: A C implementation is harder to
maintain for developers and harder to install for users, while the PHP
implementation is slower)

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

On Mon, May 9, 2011 at 5:31 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:

 On 05/08/2011 04:40 PM, Stas Malyshev wrote:

 I has been almost a month since we did our routine talk about 5.4, so
 here it goes again. The patch for the scalar hints seems to be pretty
 simple (see http://random-bits-of.info/no_scalar_hints.diff - no
 generated files included, that will be done on actual commit), so it
 should not hold us too much.
 I propose putting current code in a branch and continue without scalar
 typing for 5.4 - any objections to that?

 I would like to propose the following process (of course, dates can be
 moved around, etc. - I consider phase lengths be more important that
 actual dates, but any of them can be shifted if reason arises) for 5.4:

 - starting now - nominate features for 5.4 (see
 https://wiki.php.net/todo/php54), discussion on them
 - May 18 - start voting and debating on features that have no clear
 consensus support immediately. On the end of May is also phptek, so we
 could have some discussion there about it if needed.
 - June 15 (a bit more than a month) - alpha, branching of 5_4, open only
 for bugfixes and features in TODO list that are approved and can be done
 by beta time.
 - July 20 - beta, bugfixes only (if we add a lot of features, we may
 want to insert another 1-month alpha period, so far it doesn't look like
 it but may change)
 - Aug 24 - RC1, then an RC every 2 weeks until stable
 - Release - somewhere in October or November, depending on the RCs.

 I think we need to start moving. Not much is happening in 5.4 now as far
 as I can see, and we have a good feature set that is long due to be
 released.
 For proposing stuff for 5.4, please do it here:
 https://wiki.php.net/todo/php54 and also on the list if it wasn't
 discussed and you think it requires discussion.


 Looks good to me.

 I see the array shortcuts are on your todo discussion list there. We
 probably shouldn't get into a full discussion on that since it will span
 hundreds of messages. But if any of the folks who voted no last time around
 have changed their minds, it would be good to know. And before deciding, try
 using MongoDB from PHP for a couple of weeks. :)


maybe it would be a good idea to gather the pros/cons which was brought up
in the last discussion/poll.

another thing that I would love to see on the list: named parameters.
it was recently brought up, and I think that the original argument for the
rejection isn't true anymore:
http://www.php.net/~derick/meeting-notes.html#named-parameters
adding naming parameters would actually help to make clean and maintainable
code.
currently if you want optional params, you either have to create long list
of arguments with default values, and call your functions like
-$foo-bar($a, $b, NULL, NULL, false, $c), or you have to put your argument
into an array/object and pass that to your function, which pretty much
defeats the purpose.

I don't propose that we should hold up the release process with that, but we
should at least consider it for inclusion.

what do you think?

Tyrael

Re: [PHP-DEV] 5.4 again


Hi!


another thing that I would love to see on the list: named parameters.
it was recently brought up, and I think that the original argument for
the rejection isn't true anymore:
http://www.php.net/~derick/meeting-notes.html#named-parameters
adding naming parameters would actually help to make clean and
maintainable code.


I'm all for this idea, but the question is - can we have a good design  
implementation in next 2 months? If we can, great, if we can't - I'd 
rather have 5.4 than wait for it. E.g., if we have somebody ready to 
commit for certain timeframe to come up with it, then it makes sense to 
discuss it in this context.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Stefan Marr

Hi:

On 09 May 2011, at 09:50, Stas Malyshev wrote:

 I'm all for this idea, but the question is - can we have a good design  
 implementation in next 2 months? If we can, great, if we can't - I'd rather 
 have 5.4 than wait for it. E.g., if we have somebody ready to commit for 
 certain timeframe to come up with it, then it makes sense to discuss it in 
 this context.

Can't we just draw this arbitrary line in the sand, and say from now on, 
controversial things are taken out and nothing new is added anymore?

Everything which is not yet in trunk and is not required to round up the 
release should go into the release after 5.4?

For me it seems there is no progress because there is still to much opportunity 
to improve things...
So, instead of allowing to nominate new features, it might be best to stick to 
what we have now, and restrict ourselves to sort out the controversial stuff.


Best regards
Stefan

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

On Mon, May 9, 2011 at 9:50 AM, Stas Malyshev smalys...@sugarcrm.comwrote:

 Hi!


  another thing that I would love to see on the list: named parameters.
 it was recently brought up, and I think that the original argument for
 the rejection isn't true anymore:
 http://www.php.net/~derick/meeting-notes.html#named-parameters
 adding naming parameters would actually help to make clean and
 maintainable code.


 I'm all for this idea, but the question is - can we have a good design 
 implementation in next 2 months? If we can, great, if we can't - I'd rather
 have 5.4 than wait for it. E.g., if we have somebody ready to commit for
 certain timeframe to come up with it, then it makes sense to discuss it in
 this context.


agree.
I think we could have a good one (if somebody actually start working on it),
so I think we should leave the door open for this and if it's got written
and approved before the code freeze then we will include it.

Tyrael

Re: [PHP-DEV] 5.4 again

On Mon, May 9, 2011 at 10:00 AM, Stefan Marr p...@stefan-marr.de wrote:

 Hi:

 On 09 May 2011, at 09:50, Stas Malyshev wrote:

  I'm all for this idea, but the question is - can we have a good design 
 implementation in next 2 months? If we can, great, if we can't - I'd rather
 have 5.4 than wait for it. E.g., if we have somebody ready to commit for
 certain timeframe to come up with it, then it makes sense to discuss it in
 this context.

 Can't we just draw this arbitrary line in the sand, and say from now on,
 controversial things are taken out and nothing new is added anymore?

 Everything which is not yet in trunk and is not required to round up the
 release should go into the release after 5.4?

 For me it seems there is no progress because there is still to much
 opportunity to improve things...
 So, instead of allowing to nominate new features, it might be best to stick
 to what we have now, and restrict ourselves to sort out the controversial
 stuff.


I think that it would be nice to have a short timeframe before feature
freeze.

Tyrael

Re: [PHP-DEV] 5.4 again


Hi!


I see the array shortcuts are on your todo discussion list there. We
probably shouldn't get into a full discussion on that since it will span
hundreds of messages. But if any of the folks who voted no last time
around have changed their minds, it would be good to know. And before
deciding, try using MongoDB from PHP for a couple of weeks. :)


I agree on both discussion point and MongoDB point :) I think for things 
that were already discussed extensively it makes sense to have a vote in 
case people changed their minds and discuss at length only if they have 
something new to say - like proposing new approach to the problem - 
which is this case probably won't happen.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

Hi,

I'd love if you ever discuss these items for 5.4:

- ReflectionNamespace

Currently it's impossible to grab a docblock that documents an
Annotations, for example, or even access the namespace declaration.
It's also impossible to check which use is declared on the
namespace/file/class scope.

- Annotations

I already proposed a patch and none here discussed. You rather
preferred to shout PHP doesn't need Annotations instead of discuss
the patch that was proposed.
Actually, it was proposed twice, but it seems that you only looked at
first one (which I agree that was incompatible with PHP way of being).
Pierrick and I updated the patch to be as similar as possible with PHP
structure, but none here even looked at it. For those interested:
https://github.com/adoy/PHP-Annotations

- SplArray

We currently support SplInt, SplString, SplFloat, SplBool, etc. We
could support SplArray which would perfectly enhance implementations
that need to keep track of array state. Currently PHP provides 0
support on this area, and it would be nice if it provides a helpful
API to it. One good example to look at is:
https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Collections/Collection.php

- Comparable

Since operators overloading on PHP is hard to be implemented natively,
we could easily support it through OO. This idea can be extensively
discussed, but someone already proposed a patch previously any none
discussed it.

PS: I think that internals mailing list should be revised with all
proposed ideas and wrap them on a better plan.
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.

Regards,

On Mon, May 9, 2011 at 5:38 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!

I see the array shortcuts are on your todo discussion list there. We
probably shouldn't get into a full discussion on that since it will span
hundreds of messages. But if any of the folks who voted no last time
around have changed their minds, it would be good to know. And before
deciding, try using MongoDB from PHP for a couple of weeks. :)

I agree on both discussion point and MongoDB point :) I think for things
that were already discussed extensively it makes sense to have a vote in
case people changed their minds and discuss at length only if they have
something new to say - like proposing new approach to the problem - which is
this case probably won't happen.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Martin Scotta

Martin Scotta

On Mon, May 9, 2011 at 11:44 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:

Hi,

I'd love if you ever discuss these items for 5.4:

- ReflectionNamespace

- Annotations

- SplArray

https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Collections/Collection.php

- Comparable

Totally agree.
a user.

Regards,

On Mon, May 9, 2011 at 5:38 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!

I agree on both discussion point and MongoDB point :) I think for things
that were already discussed extensively it makes sense to have a vote in
case people changed their minds and discuss at length only if they have
something new to say - like proposing new approach to the problem - which
is
this case probably won't happen.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

2011-05-09 Thread Richard Quadling

On 9 May 2011 15:44, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
 It seems to me that you are not interested on user's request and
 rather accept/implement only what the features that interest you. It's
 very bad for the language and very bad for all of users.

But surely it is a motivational factor to learn C, and have a go at
implementing the feature yourself! That's what Open Source is all
about. If you don't like the feature, or it is missing one, _DO_
something about it. Saying that the developers are not interested
isn't really doing anything.

You really can't expect volunteers to simply down tools from family,
life, paid work to jump through hoops, attempting to make sense of
every user's request. No matter how loud they shout.

Now. If you had a pot (and a big pot) of money, then maybe you could
sponsor some developers for your pet peeve. I'll take your money.

As a volunteer to the PHP project (mainly making an arse of myself in
as many places as possible) and a PHP user, I am deeply indebted to
all the work undertaken by the core devs. I get paid because of them.

Please treat the devs nicely is all I'm really saying.

Richard.
-- 
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Philip Olson


On May 9, 2011, at 2:38 AM, Stas Malyshev wrote:

 Hi!
 
 I see the array shortcuts are on your todo discussion list there. We
 probably shouldn't get into a full discussion on that since it will span
 hundreds of messages. But if any of the folks who voted no last time
 around have changed their minds, it would be good to know. And before
 deciding, try using MongoDB from PHP for a couple of weeks. :)
 
 I agree on both discussion point and MongoDB point :) I think for things that 
 were already discussed extensively it makes sense to have a vote in case 
 people changed their minds and discuss at length only if they have something 
 new to say - like proposing new approach to the problem - which is this case 
 probably won't happen.

I'm changing my old vote, so -1 to +1. Changes and additions to syntax may (or 
may not) slow adoption, but since other such changes are being made then let's 
do it. And while explicit code (e.g., array()) is nice, many people are 
familiar with array shortcuts[1]. 

And on a related note for those at home, function array dereferencing[2] has 
already been implemented in trunk.

Also, there could probably be a discussion dedicated to arrays as other 
features/shortcuts like slicing has casually been discussed.

[1] https://wiki.php.net/rfc/shortsyntaxforarrays
[2] https://wiki.php.net/rfc/functionarraydereferencing

Regards,
Philip


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Rasmus Lerdorf


On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote:

- Annotations

I already proposed a patch and none here discussed. You rather
preferred to shout PHP doesn't need Annotations instead of discuss
the patch that was proposed.


If someone doesn't agree that annotations belong in PHP why do the 
details of the patch matter?



PS: I think that internals mailing list should be revised with all
proposed ideas and wrap them on a better plan.
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.


That's simply not true. But just because one group of users feel 
strongly about something doesn't mean it should go in. There has to be 
some level of curation or we end up with every feature under the sun 
resulting in a huge mess.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again


Hi!


It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.


Of course we are interested in user's requests, and we implemented tons 
of features at user's requests. That, however, does not mean we will 
implement _every_ requested feature, and of course for features that we 
like and understand the chance of being implemented are much higher and 
for features that core contributors don't feel make sense or go contrary 
to what they feel PHP should be the chance is low. I don't think it can 
work any other way, at least not in volunteer-driven project.


--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Marcelo Gornstein

regarding the annotations stuff: it seems the php community (in
general) really wants annotations. lots of important and widely used
frameworks use them (meaning that not only the plain php users have a
use for this feature, but also the users of the respective frameworks,
increasing the overall user number interested). i.e: doctrine,
symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.

also, this means that there are tons of custom annotations
implementations (almost one per framework that has a use for them),
and we end up duplicating code and  slowing the overall performance
for applications.

my question is: is php a language made for the php developers that
mantain the language or for the community that uses them and
contributes to it everyday?

just a thought

On Mon, May 9, 2011 at 1:44 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote:

 - Annotations

 I already proposed a patch and none here discussed. You rather
 preferred to shout PHP doesn't need Annotations instead of discuss
 the patch that was proposed.

 If someone doesn't agree that annotations belong in PHP why do the details
 of the patch matter?

 PS: I think that internals mailing list should be revised with all
 proposed ideas and wrap them on a better plan.
 It seems to me that you are not interested on user's request and
 rather accept/implement only what the features that interest you. It's
 very bad for the language and very bad for all of users.

 That's simply not true. But just because one group of users feel strongly
 about something doesn't mean it should go in. There has to be some level of
 curation or we end up with every feature under the sun resulting in a huge
 mess.

 -Rasmus

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 

--
// I don't sleep. I coffee.
Make everything as simple as possible, but not simpler. -- Albert Einstein
The class object inherits from Chuck Norris.
Chuck Norris can divide by zero and can unit test an entire
application with a single assert.
There’s a lot of work happening behind the scenes, courtesy of the
Spring AOP framework
Why do I have this nagging hunch that you have no idea what you're doing?
Any society that would give up a little liberty to gain a little
security will deserve neither and lose both - Benjamin Franklin

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Alessandro Nadalin

On Mon, May 9, 2011 at 6:55 PM, Marcelo Gornstein marce...@gmail.com wrote:
 regarding the annotations stuff: it seems the php community (in
 general) really wants annotations. lots of important and widely used
 frameworks use them (meaning that not only the plain php users have a
 use for this feature, but also the users of the respective frameworks,
 increasing the overall user number interested). i.e: doctrine,
 symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.

 also, this means that there are tons of custom annotations
 implementations (almost one per framework that has a use for them),
 and we end up duplicating code and  slowing the overall performance
 for applications.

 my question is: is php a language made for the php developers that
 mantain the language or for the community that uses them and
 contributes to it everyday?

I don't know if annotations are *needed* in PHP 5.4.
There are a few libraries, out there, that can help developers, as you
said, from now.
Doctrine's one it's really powerful, and you can clone the repo from
github and easily start using the annotation library.

So my point is to say that, although *we need a unified way to manage
annotations* ( for the reasons Marcelo just explained ), they don't
need to be a focus point for PHP 5.4.


 just a thought

 On Mon, May 9, 2011 at 1:44 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote:

 - Annotations

 I already proposed a patch and none here discussed. You rather
 preferred to shout PHP doesn't need Annotations instead of discuss
 the patch that was proposed.

 If someone doesn't agree that annotations belong in PHP why do the details
 of the patch matter?

 PS: I think that internals mailing list should be revised with all
 proposed ideas and wrap them on a better plan.
 It seems to me that you are not interested on user's request and
 rather accept/implement only what the features that interest you. It's
 very bad for the language and very bad for all of users.

 That's simply not true. But just because one group of users feel strongly
 about something doesn't mean it should go in. There has to be some level of
 curation or we end up with every feature under the sun resulting in a huge
 mess.

 -Rasmus

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





 --

 --
 // I don't sleep. I coffee.
 Make everything as simple as possible, but not simpler. -- Albert Einstein
 The class object inherits from Chuck Norris.
 Chuck Norris can divide by zero and can unit test an entire
 application with a single assert.
 There’s a lot of work happening behind the scenes, courtesy of the
 Spring AOP framework
 Why do I have this nagging hunch that you have no idea what you're doing?
 Any society that would give up a little liberty to gain a little
 security will deserve neither and lose both - Benjamin Franklin

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Lester Caine


Stas Malyshev wrote:

It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.


Of course we are interested in user's requests, and we implemented tons
of features at user's requests. That, however, does not mean we will
implement _every_ requested feature, and of course for features that we
like and understand the chance of being implemented are much higher and
for features that core contributors don't feel make sense or go contrary
to what they feel PHP should be the chance is low. I don't think it can
work any other way, at least not in volunteer-driven project.


I do feel it is about time there was a little back-pedalling and asking 'What do 
we NEED in PHP'. Personally a lot of the things that are been 'demanded' are of 
little use to make PHP work any better, and only add to the processing time. If 
people want a fully typed compiled language why aren't they using python or java 
;) My own development framework is phpeclipse, and that give me all of the 
hinting and error checking that I need IN THE EDITOR, I don't need the language 
weight down further with bells and whistles that do not improve performance of 
the end application. PHP used to be a nice nimble interpreted language that I 
can add pages to without having to compile anything. Nowadays it seems that 
those days are coming to an end? Keep the hinting and error checking to the 
tools where they belong.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] 5.4 again

2011-05-09 Thread Andi Gutmans

 -Original Message-

 From: Stas Malyshev [mailto:smalys...@sugarcrm.com]

 Sent: Sunday, May 08, 2011 4:41 PM

 To: PHP Internals

 Subject: [PHP-DEV] 5.4 again

 Hi!

 I has been almost a month since we did our routine talk about 5.4, so here it

 goes again. The patch for the scalar hints seems to be pretty simple (see

 http://random-bits-of.info/no_scalar_hints.diff - no generated files included,

 that will be done on actual commit), so it should not hold us too much.

 I propose putting current code in a branch and continue without scalar typing

 for 5.4 - any objections to that?

-snip-

 I think we need to start moving. Not much is happening in 5.4 now as far as I

 can see, and we have a good feature set that is long due to be released.

 For proposing stuff for 5.4, please do it here:

 https://wiki.php.net/todo/php54 and also on the list if it wasn't discussed 
 and

 you think it requires discussion.

As I've already pointed out, I am all in favor of starting to run the release 
process.

I do think we should focus on getting out there what we have now (with some 
tweaks) and not trying to do major new features or we will by definition not be 
entering a release process. The richer our language (and the more mature and 
broad our base) the more we have to be concerned with feature creep.

- On performance  memory consumption - as already mentioned, huge 
improvements! We may be able to do more but will stay within the release 
timeline if we make any further improvements.

- On square bracket shortcut I was always in favor of (b) in 
http://marc.info/?l=php-internalsm=11385524494w=2. If this is what we're 
talking about I personally feel it's an easy one.

- Agree type hints goes out.

Go!!

Andi

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Matthew Weier O'Phinney

On 2011-05-09, Marcelo Gornstein marce...@gmail.com wrote:
 regarding the annotations stuff: it seems the php community (in
 general) really wants annotations. lots of important and widely used
 frameworks use them (meaning that not only the plain php users have a
 use for this feature, but also the users of the respective frameworks,
 increasing the overall user number interested). i.e: doctrine,
 symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.

There are annotations, and annotations. Some folks are perfectly fine
with ad-hoc annotations support possible by parsing docblocks (Sebastian
B. has mentioned as much in relation to PHPUnit). Others are wanting
what is essentially a new, parsable, syntax on top of PHP. Others are
interested in this latter, but feel that a userland parser that uses
code generation to produce executable PHP code is sufficient. 

The point is, there's still debate about whether the feature as proposed
is needed, and, if so, the full scope of features required to support
it, and what implications those have for the language.

 also, this means that there are tons of custom annotations
 implementations (almost one per framework that has a use for them),
 and we end up duplicating code and  slowing the overall performance
 for applications.

 my question is: is php a language made for the php developers that
 mantain the language or for the community that uses them and
 contributes to it everyday?

 just a thought

 On Mon, May 9, 2011 at 1:44 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote:

 - Annotations

 I already proposed a patch and none here discussed. You rather
 preferred to shout PHP doesn't need Annotations instead of discuss
 the patch that was proposed.

 If someone doesn't agree that annotations belong in PHP why do the details
 of the patch matter?

 PS: I think that internals mailing list should be revised with all
 proposed ideas and wrap them on a better plan.
 It seems to me that you are not interested on user's request and
 rather accept/implement only what the features that interest you. It's
 very bad for the language and very bad for all of users.

 That's simply not true. But just because one group of users feel strongly
 about something doesn't mean it should go in. There has to be some level of
 curation or we end up with every feature under the sun resulting in a huge
 mess.

 -Rasmus

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php







-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

Hi Rasmus,

On Mon, May 9, 2011 at 1:44 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote:

 - Annotations

 I already proposed a patch and none here discussed. You rather
 preferred to shout PHP doesn't need Annotations instead of discuss
 the patch that was proposed.

 If someone doesn't agree that annotations belong in PHP why do the details
 of the patch matter?

The actual concern is that someone didn't agree with that and (re-read
the thread to comment this), also confirmed that never used
Annotations and have a very superficial knowledge of the
possibilities, than to me it's more than clear to me that it's not a
valid opinion. If it is for you, then PHP has a problem.


 PS: I think that internals mailing list should be revised with all
 proposed ideas and wrap them on a better plan.
 It seems to me that you are not interested on user's request and
 rather accept/implement only what the features that interest you. It's
 very bad for the language and very bad for all of users.

 That's simply not true. But just because one group of users feel strongly
 about something doesn't mean it should go in. There has to be some level of
 curation or we end up with every feature under the sun resulting in a huge
 mess.

Are you sure?
Please take a look at every topic defined on wiki page. Is there ANY
topic to be discussed that came from userland?
If you say yes, please point me to the thread. What I clearly see
there is that every feature defined there came from users with php-src
karma.
Now I re-ask you, are you really sure it's only a small group that
want something or do you now confirm that only php-src users have
relevance on features request?


 -Rasmus




-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Christopher Jones




On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote:


It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.


Rasmus  Stas have already pointed out this is not valid and lots of
user requests are implemented.

I'd add that PHP has never had a lot of spare developer capacity.
Programmers are not idly sitting around, waiting for random ideas to
code up.  If you feel strongly about a feature you have to convince
the core contributors of its merits and (i) pique the interest of
someone capable of implementing it and then help with testing and
documentation, or (ii) implement it all yourself.

It's easier than ever to get an SVN account, so contributing would
be a good way to get karma.

Chris

--
Email: christopher.jo...@oracle.com
Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again


Hi!


- ReflectionNamespace
- Annotations
- SplArray
- Comparable


Thanks for the list, it's a good start of the discussion. I have only 
one note for now - since the goal of all this to try and get 5.4 out 
before the end of the year, I think that requires some scope limiting.


By this I mean that if something is proposed to which the implementation 
or design isn't obvious, there should be commitment for it to be done in 
next 2 months. By done I mean both having design with reasonable 
consensus and full implementation.


So if somebody proposes something entirely new that the implementation 
is not obvious or already existing, he should either make commitment to 
do this in the next 2 months personally or find somebody who will. Of 
course, 2 months here doesn't mean exactly 61 days, but it's the 
timeframe. I.e., if it's an idea let's somebody do it - it might be a 
perfectly good idea, but not for this 5.4. That doesn't mean it's 
rejected - it just would be out of scope for this release.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

Hi Richard,

Again what I commented on other thread and again you barely see what I
mentioned, the feature is ALREADY written in C and compatible with
latest PHP trunk.
I'm not bitching against do and don't dos... I'm bitching about
ignored feature that are not even discussed.

I agree with you, it's an Open Source project and any help from any
front is valuable.
But as I pointed out on other thread, only developers with php-src
karma had features evaluated.
If you think I'm wrong, please re-read the entire thread of
Annotations and then get back to me with a single message on thread
where actually had a discussion with some mature content instead of
personal feelings.

Regards,

On Mon, May 9, 2011 at 1:13 PM, Richard Quadling rquadl...@gmail.com wrote:
 On 9 May 2011 15:44, guilhermebla...@gmail.com
 guilhermebla...@gmail.com wrote:
 It seems to me that you are not interested on user's request and
 rather accept/implement only what the features that interest you. It's
 very bad for the language and very bad for all of users.

 But surely it is a motivational factor to learn C, and have a go at
 implementing the feature yourself! That's what Open Source is all
 about. If you don't like the feature, or it is missing one, _DO_
 something about it. Saying that the developers are not interested
 isn't really doing anything.

 You really can't expect volunteers to simply down tools from family,
 life, paid work to jump through hoops, attempting to make sense of
 every user's request. No matter how loud they shout.

 Now. If you had a pot (and a big pot) of money, then maybe you could
 sponsor some developers for your pet peeve. I'll take your money.

 As a volunteer to the PHP project (mainly making an arse of myself in
 as many places as possible) and a PHP user, I am deeply indebted to
 all the work undertaken by the core devs. I get paid because of them.

 Please treat the devs nicely is all I'm really saying.

 Richard.
 --
 Richard Quadling
 Twitter : EE : Zend
 @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] 5.4 again

2011-05-09 Thread Andi Gutmans

 -Original Message-

 From: Christopher Jones [mailto:christopher.jo...@oracle.com]

 Sent: Monday, May 09, 2011 10:28 AM

 To: internals@lists.php.net; Guilherme Blanco

 Subject: Re: [PHP-DEV] 5.4 again

 On 05/09/2011 07:44 AM, 
 guilhermebla...@gmail.commailto:guilhermebla...@gmail.com wrote:

  It seems to me that you are not interested on user's request and

  rather accept/implement only what the features that interest you. It's

  very bad for the language and very bad for all of users.

 Rasmus  Stas have already pointed out this is not valid and lots of user

 requests are implemented.

 I'd add that PHP has never had a lot of spare developer capacity.

 Programmers are not idly sitting around, waiting for random ideas to code

 up.  If you feel strongly about a feature you have to convince the core

 contributors of its merits and (i) pique the interest of someone capable of

 implementing it and then help with testing and documentation, or (ii)

 implement it all yourself.

 It's easier than ever to get an SVN account, so contributing would be a good

 way to get karma.

I agree but also want to emphasize that just because there’s a patch it doesn’t 
mean it’s a good idea and should be accepted.

Of course like Chris points out it’ll significantly increase the chances of 
people taking it seriously and playing around with the idea.

I also think Matthew makes a good point – annotations can be viewed in 
different ways and arguably there are already quite a lot of possibilities with 
what exists today.

Andi

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

2011-05-09 Thread Rasmus Lerdorf


On 05/09/2011 10:32 AM, guilhermebla...@gmail.com wrote:

Hi Richard,

Again what I commented on other thread and again you barely see what I
mentioned, the feature is ALREADY written in C and compatible with
latest PHP trunk.
I'm not bitching against do and don't dos... I'm bitching about
ignored feature that are not even discussed.

I agree with you, it's an Open Source project and any help from any
front is valuable.
But as I pointed out on other thread, only developers with php-src
karma had features evaluated.
If you think I'm wrong, please re-read the entire thread of
Annotations and then get back to me with a single message on thread
where actually had a discussion with some mature content instead of
personal feelings.


A lot of people who understand the problem very well weighed in on this 
feature. Framework authors and others who have a real use for 
annotations, and there was still no clear agreement.


As far as RFCs on the wiki only coming from people with php-src 
accounts, that is true, since that is our auth system for the wiki. But 
getting an account, even if it is simply to submit an RFC to the wiki is 
rather trivial.


Or looking at it another way, if the feature is so popular, getting one 
of the 2000 people with an account to submit the RFC shouldn't be a problem.


-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again



  That's simply not true. But just because one group of users feel strongly
  about something doesn't mean it should go in. There has to be some level
 of
  curation or we end up with every feature under the sun resulting in a
 huge
  mess.

 Are you sure?
 Please take a look at every topic defined on wiki page. Is there ANY
 topic to be discussed that came from userland?
 If you say yes, please point me to the thread. What I clearly see
 there is that every feature defined there came from users with php-src
 karma.


there is at least one, mine

but I also think that the core devs and the php userland/community is too
far away, we would need more people from the userland to contribute to the
development of the php language.
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6“Because
it’s nearly impossible toparticipate on Internals if yourpoo-throwing arm
isn’t strong.” — @coates
“Those with talent, competence, energy,and good ideas over a period of time
- and who outlast the rest - tend to be the main drivers behind
PHPdevelopment.”  — @a

Tyrael

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

Rasmus,

I already wrote an RFC, I already wrote a patch and none from php-src
gave me some valuable feedback.
During private conversations while flaming messages were popping on ML
thread, I updated the code to be more PHP compatible and when I went
to update the RFC on wiki, it became offline.

BTW, if you think Annotations wouldn't be so popular, please tell the
Symfony users (Routing, Validation), Doctrine users (Entire Mapping),
Typo3 users, Zend Framework (XML-RPC), PHPUnit users that this feature
is useless. If this doesn't count 2000 users using the feature, I
think only wordpress users may count this.

Cheers,

On Mon, May 9, 2011 at 2:38 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 05/09/2011 10:32 AM, guilhermebla...@gmail.com wrote:

 Hi Richard,

 Again what I commented on other thread and again you barely see what I
 mentioned, the feature is ALREADY written in C and compatible with
 latest PHP trunk.
 I'm not bitching against do and don't dos... I'm bitching about
 ignored feature that are not even discussed.

 I agree with you, it's an Open Source project and any help from any
 front is valuable.
 But as I pointed out on other thread, only developers with php-src
 karma had features evaluated.
 If you think I'm wrong, please re-read the entire thread of
 Annotations and then get back to me with a single message on thread
 where actually had a discussion with some mature content instead of
 personal feelings.

 A lot of people who understand the problem very well weighed in on this
 feature. Framework authors and others who have a real use for annotations,
 and there was still no clear agreement.

 As far as RFCs on the wiki only coming from people with php-src accounts,
 that is true, since that is our auth system for the wiki. But getting an
 account, even if it is simply to submit an RFC to the wiki is rather
 trivial.

 Or looking at it another way, if the feature is so popular, getting one of
 the 2000 people with an account to submit the RFC shouldn't be a problem.

 -Rasmus




-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

Hi Andi,

That's all I want.
Someone to at least look at the patch and give me feedback.
None here did that, all you're doing is telling no, we don't accept it.

Why don't you give me some valuable feedback so I can work on the
patch to turn it relevant to you?

Regards,

On Mon, May 9, 2011 at 2:33 PM, Andi Gutmans a...@zend.com wrote:
 -Original Message-

 From: Christopher Jones [mailto:christopher.jo...@oracle.com]

 Sent: Monday, May 09, 2011 10:28 AM

 To: internals@lists.php.net; Guilherme Blanco

 Subject: Re: [PHP-DEV] 5.4 again







 On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote:



  It seems to me that you are not interested on user's request and

  rather accept/implement only what the features that interest you. It's

  very bad for the language and very bad for all of users.



 Rasmus  Stas have already pointed out this is not valid and lots of user

 requests are implemented.



 I'd add that PHP has never had a lot of spare developer capacity.

 Programmers are not idly sitting around, waiting for random ideas to code

 up.  If you feel strongly about a feature you have to convince the core

 contributors of its merits and (i) pique the interest of someone capable
 of

 implementing it and then help with testing and documentation, or (ii)

 implement it all yourself.



 It's easier than ever to get an SVN account, so contributing would be a
 good

 way to get karma.



 I agree but also want to emphasize that just because there’s a patch it
 doesn’t mean it’s a good idea and should be accepted.

 Of course like Chris points out it’ll significantly increase the chances of
 people taking it seriously and playing around with the idea.



 I also think Matthew makes a good point – annotations can be viewed in
 different ways and arguably there are already quite a lot of possibilities
 with what exists today.



 Andi



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

2011-05-09 Thread Rasmus Lerdorf


On 05/09/2011 10:48 AM, guilhermebla...@gmail.com wrote:

Rasmus,

I already wrote an RFC, I already wrote a patch and none from php-src
gave me some valuable feedback.
During private conversations while flaming messages were popping on ML
thread, I updated the code to be more PHP compatible and when I went
to update the RFC on wiki, it became offline.

BTW, if you think Annotations wouldn't be so popular, please tell the
Symfony users (Routing, Validation), Doctrine users (Entire Mapping),
Typo3 users, Zend Framework (XML-RPC), PHPUnit users that this feature
is useless. If this doesn't count 2000 users using the feature, I
think only wordpress users may count this.


Nobody has argued that there isn't a use for annotations. There 
obviously is. The argument is whether it needs to be in the core of the 
language when it isn't inherently a runtime thing. A single standard for 
annotations and non-runtime tools for manipulating that standard is a 
viable approach as well. That is what people are doing now, except they 
all picked different ways of doing it. By putting it into the core you 
are solving that problem since everyone will likely switch to it, but 
the argument is that that is not a good enough justification for putting 
it into the core of the language.


-Rasmus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

Hi Rasmus,

Thanks a lot for the response. This was the first email that I got
that is not rude against my patch.

I have worked on Doctrine annotations support (which is being used by
Symfony and also Typo3), which is a LL(*) parser that processes
docblocks and uses runtime classes to build associated information.
This relies on 2 points to correctly work: a reader and a cache. These
ones are required for 2 reasons:
- PHP doesn't currently support annotations (so
ReflecionClass/ReflectionProperty/ReflectionMethod cannot have a
simplified API to getAnnotations()). The Reader is a composition over
ReflectionAPI.
- Parsing is expensive and I cannot plugin opcache. To fix the
overhead of processing every request, I plugged a cache support.

What I thought it could be changed is:
- Allow PHP to support it natively and also take advantage of opcode cache
- Make API cleaner

That's where the idea came.
I voted for having it native to ZE because a code with and without
comments should behave the same. So this made me to work on something
that could be merged into php-src.

If possible, could you look at the patch and give me high level ideas
of what could be changed?

Thanks

On Mon, May 9, 2011 at 2:53 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 05/09/2011 10:48 AM, guilhermebla...@gmail.com wrote:

 Rasmus,

 I already wrote an RFC, I already wrote a patch and none from php-src
 gave me some valuable feedback.
 During private conversations while flaming messages were popping on ML
 thread, I updated the code to be more PHP compatible and when I went
 to update the RFC on wiki, it became offline.

 BTW, if you think Annotations wouldn't be so popular, please tell the
 Symfony users (Routing, Validation), Doctrine users (Entire Mapping),
 Typo3 users, Zend Framework (XML-RPC), PHPUnit users that this feature
 is useless. If this doesn't count 2000 users using the feature, I
 think only wordpress users may count this.

 Nobody has argued that there isn't a use for annotations. There obviously
 is. The argument is whether it needs to be in the core of the language when
 it isn't inherently a runtime thing. A single standard for annotations and
 non-runtime tools for manipulating that standard is a viable approach as
 well. That is what people are doing now, except they all picked different
 ways of doing it. By putting it into the core you are solving that problem
 since everyone will likely switch to it, but the argument is that that is
 not a good enough justification for putting it into the core of the
 language.

 -Rasmus





-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)


Hi!


I'm not bitching against do and don't dos... I'm bitching about
ignored feature that are not even discussed.


I think annotations were discussed very extensively. But I totally can 
see how one particular aspect could slip through. In this case it is 
right to remind people about it and restart the discussion - by stating 
what exactly was missed and what new was out there that in your opinion 
didn't get enough attention.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Stefan Marr

Hi:

On 09 May 2011, at 19:25, guilhermebla...@gmail.com wrote:

 Are you sure?
 Please take a look at every topic defined on wiki page. Is there ANY
 topic to be discussed that came from userland?
 If you say yes, please point me to the thread. What I clearly see
 there is that every feature defined there came from users with php-src
 karma.
 Now I re-ask you, are you really sure it's only a small group that
 want something or do you now confirm that only php-src users have
 relevance on features request?

Just for the sake of argument, a single counter-example can prove you wrong.

And that counter-example is traits.
I implemented the traits long before I got actual karma, and why do we have 
traits in trunk now?
Because I kept arguing that they are useful, and that I as a user want them.
Others liked the idea, and eventually I got the karma to push the code into the 
official repository.

First it was developed completely outside of PHP and without asking anyone from 
internals, just because I wanted it...

That is how open source works.

Best regards
Stefan




-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

2011-05-09 Thread Lester Caine


guilhermebla...@gmail.com wrote:

What I thought it could be changed is:
- Allow PHP to support it natively and also take advantage of opcode cache
- Make API cleaner


Guilherme you still also have to explain WHY we need this. I have a perfectly 
functional documentation and hinting setup working from docblock entries in 
several years worth of code. Rewriting all of that would have to have some 
reason, and working with two systems in parallel does not make sense. My current 
method of working is well supported in phpeclipse while your new offering will 
require some major work in phpeclipse and other tools simply to access it? More 
work for other open source developers who again probably don't need it. So as 
far as I am concerned I need to be persuaded why this code needs to be IN the 
core code when I for one can't see any reason to use it. Just because COMPILED 
languages have it is not a reason to load an interpreted language with it. 
Adding it as a removable extension might make more sense to me, just as much of 
the less used code can be disabled if we want. And I was coding in C/C++ long 
before I switched TO PHP to get away from the problems of using compiled 
languages for dynamic web based systems.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread dukeofgaming

On Mon, May 9, 2011 at 12:44 PM, Ferenc Kovacs i...@tyrael.hu wrote:

That's simply not true. But just because one group of users feel
strongly
about something doesn't mean it should go in. There has to be some
level
of
curation or we end up with every feature under the sun resulting in a
huge
mess.

Are you sure?
Please take a look at every topic defined on wiki page. Is there ANY
topic to be discussed that came from userland?
If you say yes, please point me to the thread. What I clearly see
there is that every feature defined there came from users with php-src
karma.

there is at least one, mine

but I also think that the core devs and the php userland/community is too
far away, we would need more people from the userland to contribute to the
development of the php language.

http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6

http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
“Because
it’s nearly impossible toparticipate on Internals if yourpoo-throwing arm
isn’t strong.” — @coates
“Those with talent, competence, energy,and good ideas over a period of time
- and who outlast the rest - tend to be the main drivers behind
PHPdevelopment.” — @a

Tyrael

Hi,

After having some experience participating in other open-source communities,
specially Joomla (but also Mootools, Doctrine and Symfony), my first
impression when subscribing and reading this list was: wow, its hostile,
and I automatically refrained from wanting to participate and chose just to
observe for the meantime.

I know every community is different, but, even if a single person states
something that might look like a problem it is an indicator that you might
have it.

I think the PHP community could benefit from a process like Python's PEP
Workflow: http://www.python.org/dev/peps/pep-0001/#pep-work-flow.

Personal attacks achieve nothing, and contributing to open-source is MORE
than contributing code, and even if you do contribute, it doesn't look like
it is even an automatic way to get the needed attention. I've seen Guilherme
post several times asking for feedback (i.e. building upon his work, not
just criticizing him) and I have never seen it. I don't think Guilherme
loves spending his afternoons advancing in a patch without the slightest
sense of community direction.

Being brutally honest, looks to me that this generalized attitude/culture
might actually be scaring willing devs away, and the community itself needs
some kind of direction. Here is a recommended watch:

O'Reilly MySQL CE 2010: Jono Bacon, The Engines Of Community:
http://blip.tv/file/3495291

Best regards,

David

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread Ilia Alshanetsky

Seems like a good plan to me. Hopefully as per schedule it gets us 5.4
this year.

On Sun, May 8, 2011 at 7:40 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 I has been almost a month since we did our routine talk about 5.4, so here
 it goes again. The patch for the scalar hints seems to be pretty simple (see
 http://random-bits-of.info/no_scalar_hints.diff - no generated files
 included, that will be done on actual commit), so it should not hold us too
 much.
 I propose putting current code in a branch and continue without scalar
 typing for 5.4 - any objections to that?

 I would like to propose the following process (of course, dates can be moved
 around, etc. - I consider phase lengths be more important that actual dates,
 but any of them can be shifted if reason arises) for 5.4:

 - starting now - nominate features for 5.4 (see
 https://wiki.php.net/todo/php54), discussion on them
 - May 18 - start voting and debating on features that have no clear
 consensus support immediately. On the end of May is also phptek, so we could
 have some discussion there about it if needed.
 - June 15 (a bit more than a month) - alpha, branching of 5_4, open only for
 bugfixes and features in TODO list that are approved and can be done by beta
 time.
 - July 20 - beta, bugfixes only (if we add a lot of features, we may want to
 insert another 1-month alpha period, so far it doesn't look like it but may
 change)
 - Aug 24 - RC1, then an RC every 2 weeks until stable
 - Release - somewhere in October or November, depending on the RCs.

 I think we need to start moving. Not much is happening in 5.4 now as far as
 I can see, and we have a good feature set that is long due to be released.
 For proposing stuff for 5.4, please do it here:
 https://wiki.php.net/todo/php54 and also on the list if it wasn't discussed
 and you think it requires discussion.

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] 5.4 again

2011-05-09 Thread Andi Gutmans

-Original Message-

From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]

Sent: Monday, May 09, 2011 10:51 AM

To: Andi Gutmans

Cc: Christopher Jones; internals@lists.php.net

Subject: Re: [PHP-DEV] 5.4 again

Hi Andi,

That's all I want.

Someone to at least look at the patch and give me feedback.

None here did that, all you're doing is telling no, we don't accept it.

Why don't you give me some valuable feedback so I can work on the patch to

turn it relevant to you?

I think more important than the patch is the actual functionality. Patch can 
always be fixed.

I assume the latest RFC is https://wiki.php.net/rfc/annotations?

I will take a bit of a longer look at it in the coming days but from looking at 
it quickly I can see why some people may not be very excited about it. I 
personally have never been a huge fan of meta-data whether in the code or 
outside the code. The biggest scars I carry are from J2EE. I feel annotations 
are sometimes just a nicer way of creating similar problems (hard to understand 
flow, hard to debug, etc…). I do realize there are also some benefits but as 
Matthew pointed out the question is are those benefits enough to warrant a 
whole new grammar in the language or do we keep it lighter weight and let 
people build on that (which with the right caching should not be too hard).

Anyway, I will take a longer look.

Andi (hoping I don’t get extra newlines this time around. My apologies but for 
some reason my mail client doesn’t like internals@ in the past two weeks).

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

Hi Lester,

I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)

Here is the direct link: https://wiki.php.net/rfc/annotations

Regards,

On Mon, May 9, 2011 at 6:42 PM, Lester Caine les...@lsces.co.uk wrote:
 guilhermebla...@gmail.com wrote:

 What I thought it could be changed is:
 - Allow PHP to support it natively and also take advantage of opcode cache
 - Make API cleaner

 Guilherme you still also have to explain WHY we need this. I have a
 perfectly functional documentation and hinting setup working from docblock
 entries in several years worth of code. Rewriting all of that would have to
 have some reason, and working with two systems in parallel does not make
 sense. My current method of working is well supported in phpeclipse while
 your new offering will require some major work in phpeclipse and other tools
 simply to access it? More work for other open source developers who again
 probably don't need it. So as far as I am concerned I need to be persuaded
 why this code needs to be IN the core code when I for one can't see any
 reason to use it. Just because COMPILED languages have it is not a reason to
 load an interpreted language with it. Adding it as a removable extension
 might make more sense to me, just as much of the less used code can be
 disabled if we want. And I was coding in C/C++ long before I switched TO PHP
 to get away from the problems of using compiled languages for dynamic web
 based systems.

 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk//
 Firebird - http://www.firebirdsql.org/index.php

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 again

Hi Andi,

Sorry, but I mentioned on other thread that RFC is outdated.
I just finished an update to it bringing to recent implementation. The
idea is to get the big picture here, I may have left from previous
RFC, but if I did that, please just point out and I can fix.
This implementation is *way* simpler.

Here is the direct link: https://wiki.php.net/rfc/annotations

Regards,

On Mon, May 9, 2011 at 7:39 PM, Andi Gutmans a...@zend.com wrote:
-Original Message-

From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]

Sent: Monday, May 09, 2011 10:51 AM

To: Andi Gutmans

Cc: Christopher Jones; internals@lists.php.net

Subject: Re: [PHP-DEV] 5.4 again



Hi Andi,



That's all I want.

Someone to at least look at the patch and give me feedback.

None here did that, all you're doing is telling no, we don't accept it.



Why don't you give me some valuable feedback so I can work on the patch to

turn it relevant to you?



 I think more important than the patch is the actual functionality. Patch can
 always be fixed.

 I assume the latest RFC is https://wiki.php.net/rfc/annotations?



 I will take a bit of a longer look at it in the coming days but from looking
 at it quickly I can see why some people may not be very excited about it. I
 personally have never been a huge fan of meta-data whether in the code or
 outside the code. The biggest scars I carry are from J2EE. I feel
 annotations are sometimes just a nicer way of creating similar problems
 (hard to understand flow, hard to debug, etc…). I do realize there are also
 some benefits but as Matthew pointed out the question is are those benefits
 enough to warrant a whole new grammar in the language or do we keep it
 lighter weight and let people build on that (which with the right caching
 should not be too hard).

 Anyway, I will take a longer look.



 Andi (hoping I don’t get extra newlines this time around. My apologies but
 for some reason my mail client doesn’t like internals@ in the past two
 weeks).



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

2011-05-09 Thread Lester Caine


guilhermebla...@gmail.com wrote:

Hi Lester,

I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)

Here is the direct link: https://wiki.php.net/rfc/annotations
But there is nothing there that explains why this is any use where we are not 
compiling code ... and are all things we are already doing with comment blocks 
... which CAN be stripped to speed up operation once in a production 
environment. A compiler simply strips the unnecessary stuff when building the 
running code, how do you propose PHP does that ? If I want compiled code then I 
can use any number of other languages, PHP simply runs what I have in the file.



Regards,

On Mon, May 9, 2011 at 6:42 PM, Lester Caineles...@lsces.co.uk  wrote:

guilhermebla...@gmail.com wrote:


What I thought it could be changed is:
- Allow PHP to support it natively and also take advantage of opcode cache
- Make API cleaner


Guilherme you still also have to explain WHY we need this. I have a
perfectly functional documentation and hinting setup working from docblock
entries in several years worth of code. Rewriting all of that would have to
have some reason, and working with two systems in parallel does not make
sense. My current method of working is well supported in phpeclipse while
your new offering will require some major work in phpeclipse and other tools
simply to access it? More work for other open source developers who again
probably don't need it. So as far as I am concerned I need to be persuaded
why this code needs to be IN the core code when I for one can't see any
reason to use it. Just because COMPILED languages have it is not a reason to
load an interpreted language with it. Adding it as a removable extension
might make more sense to me, just as much of the less used code can be
disabled if we want. And I was coding in C/C++ long before I switched TO PHP
to get away from the problems of using compiled languages for dynamic web
based systems.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)


Hi!


I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)

Here is the direct link: https://wiki.php.net/rfc/annotations


Some questions I didn't find the answers in the RFC:
1. When the annotation objects are instantiated?
2. What is permissible in the arguments of annotation - e.g. can I put 
any expression there?

3. What Foo(Bar) actually means and how it is supposed to be parsed?
4. What happens if ctor for annotation has error/exception?
5. Are there any limitations on classes that can be used as annotations?
6. Do we need any special support for bytecode caches?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

Hi Lester,

What you don't see is that you're against having it because you
already had the effort to built this support.
So answering your question related to use cases, you own codebase is a
good example.

You had to create a parser for docblock because PHP doesn't have
support. And now you're asking me why is it needed because you already
implemented it. It's like chicken and eggs.
You wouldn't need to implement a docblock parser IF PHP already supported it.

Also, you own comments answer you own question. You compile your
code for production removing the docblocks (or adding a cache, or
generating a file, etc, whatever you want). What does it prohibit you
from doing the same with native support?


Regards,

On Mon, May 9, 2011 at 9:25 PM, Lester Caine les...@lsces.co.uk wrote:
 guilhermebla...@gmail.com wrote:

 Hi Lester,

 I updated the RFC. I may have missed one thing or two, but overall
 idea and how code behave is there.
 This question is answered on wiki RFC. =)

 Here is the direct link: https://wiki.php.net/rfc/annotations

 But there is nothing there that explains why this is any use where we are
 not compiling code ... and are all things we are already doing with comment
 blocks ... which CAN be stripped to speed up operation once in a production
 environment. A compiler simply strips the unnecessary stuff when building
 the running code, how do you propose PHP does that ? If I want compiled code
 then I can use any number of other languages, PHP simply runs what I have in
 the file.

 Regards,

 On Mon, May 9, 2011 at 6:42 PM, Lester Caineles...@lsces.co.uk  wrote:

 guilhermebla...@gmail.com wrote:

 What I thought it could be changed is:
 - Allow PHP to support it natively and also take advantage of opcode
 cache
 - Make API cleaner

 Guilherme you still also have to explain WHY we need this. I have a
 perfectly functional documentation and hinting setup working from
 docblock
 entries in several years worth of code. Rewriting all of that would have
 to
 have some reason, and working with two systems in parallel does not make
 sense. My current method of working is well supported in phpeclipse while
 your new offering will require some major work in phpeclipse and other
 tools
 simply to access it? More work for other open source developers who again
 probably don't need it. So as far as I am concerned I need to be
 persuaded
 why this code needs to be IN the core code when I for one can't see any
 reason to use it. Just because COMPILED languages have it is not a reason
 to
 load an interpreted language with it. Adding it as a removable extension
 might make more sense to me, just as much of the less used code can be
 disabled if we want. And I was coding in C/C++ long before I switched TO
 PHP
 to get away from the problems of using compiled languages for dynamic web
 based systems.

 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk//
 Firebird - http://www.firebirdsql.org/index.php

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)

Hi Stas,

On Mon, May 9, 2011 at 9:35 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 I updated the RFC. I may have missed one thing or two, but overall
 idea and how code behave is there.
 This question is answered on wiki RFC. =)

 Here is the direct link: https://wiki.php.net/rfc/annotations

 Some questions I didn't find the answers in the RFC:
 1. When the annotation objects are instantiated?

Objects are only instantiated when requested (getAnnotations() or
getAnnotation())

 2. What is permissible in the arguments of annotation - e.g. can I put any
 expression there?

You are allowed to use any scalar value + array + any object that
implements ReflectionAnnotation interface.

 3. What Foo(Bar) actually means and how it is supposed to be parsed?

It would instantiate a class Bar and would pass it as an instance of
Foo that is also being created when doing getAnnotations() or
getAnnotation('Foo')

 4. What happens if ctor for annotation has error/exception?

There're error support just like PHP has. Here is a sample:

Fatal error: Uncaught exception 'Exception' with message 'Fo' in
/src/php-src/trunk/ok.php:6
Stack trace:
#0 [internal function]: simpleannotation-__construct()
#1 /src/php-src/trunk/ok.php(15):
ReflectionClass-getAnnotation('simpleannotatio...')
#2 {main}
  thrown in /src/php-src/trunk/ok.php on line 6

Code:

class SimpleAnnotation implements ReflectionAnnotation {
public function __construct()
{
throw new Exception('Fo');
}
}

SimpleAnnotation
class Foo {
}

$r = new ReflectionClass('Foo');
var_dump($r-getAnnotation('SimpleAnnotation'));

 5. Are there any limitations on classes that can be used as annotations?

As I said, only classes that implement ReflectionAnnotation are
allowed to be used. It gives errors if you attempt to do something
invalid.
Here is the error you get if you attempt to use a non-declared annotation:

class Foo implements ReflectionAnnotation {
public function __construct($bar)
{}
}

class Bar {}

Foo(Bar)
class FooBar {
}

$r = new ReflectionClass('FooBar');
var_dump($r-getAnnotations());

Fatal error: ReflectionClass::getAnnotations(): 'Bar' must implement
'ReflectionAnnotation' to act as an annotation in - on line 15


 6. Do we need any special support for bytecode caches?

Yes. Every structure which can be annotated now will have a new member
in their C structure which is annotations, this structure is populated
at compile time and store all the metadata information. So if you have
an opcode cache the compilation will not occur, so the annotations
will be NULL. That's why the opcode cache will have to store the
annotations, so that it can be retrieved every time.


 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227




-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)