2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With this patch, something looks inconsistent to me:
Both properties and methods have a visibility
(public|protected|private) and a keyword: var (T_VAR) and function
(T_FUNCTION)
I toast to that. Get rid of T_VAR already.
Regards,
David
On Thu, Dec 2, 2010 at 3:34 AM, Patrick ALLAERT patrickalla...@php.netwrote:
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With this patch, something looks inconsistent to
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.netwrote:
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With this patch, something looks inconsistent to me:
Both properties and methods have a visibility
How about deprecation then?
On Thu, Dec 2, 2010 at 3:58 AM, André Rømcke a...@ez.no wrote:
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net
wrote:
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With
2010/12/2 André Rømcke a...@ez.no:
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net
wrote:
Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
introducing the possible omission of T_FUNCTION?
Why?
This will break lots of code, does it improve anything while
On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT patrickalla...@php.net wrote:
2010/12/2 André Rømcke a...@ez.no:
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net
wrote:
Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
introducing the possible omission of
2010/12/2 Peter Beverloo pe...@lvp-media.com:
On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT patrickalla...@php.net wrote:
2010/12/2 André Rømcke a...@ez.no:
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net
wrote:
Shouldn't we get rid of that kind of pre-PHP5 stuff
On 12/2/10 7:51 AM, Patrick ALLAERT wrote:
+1 for removing T_VAR and making T_FUNCTION optional in a major release.
-1 otherwise.
I am still firmly -1 on removing T_FUNCTION for methods.
--
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor
--
PHP Internals -
On Thu, Dec 2, 2010 at 17:07, la...@garfieldtech.com
la...@garfieldtech.com wrote:
On 12/2/10 7:51 AM, Patrick ALLAERT wrote:
+1 for removing T_VAR and making T_FUNCTION optional in a major release.
-1 otherwise.
I am still firmly -1 on removing T_FUNCTION for methods.
--
Patrick Allaert
-1
On 11/27/2010 08:40 PM, Johannes Schlüter wrote:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the parser
2010/11/27 Johannes Schlüter johan...@schlueters.de
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the parser to
2010/11/27 Johannes Schlüter johan...@schlueters.de:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the parser to
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
With this patch, something looks inconsistent to me:
Both properties and methods have a visibility
(public|protected|private) and a keyword: var (T_VAR) and function
(T_FUNCTION) respectively.
However private var $foo; generates a fatal
my +1 for new major version only, btw :)
2010/11/27 Pierre Joye pierre@gmail.com:
+1 if While technically possible this RFC suggests that the following
shall NOT be valid for keeping the code readable also means that the
patch implements it as well (force the function visibility property
+1 for next major, but not for middle point release. =)
2010/11/29 Pierre Joye pierre@gmail.com:
my +1 for new major version only, btw :)
2010/11/27 Pierre Joye pierre@gmail.com:
+1 if While technically possible this RFC suggests that the following
shall NOT be valid for keeping the
Hi!
Sorry for moving offtopic, but if the PHP syntax is going to change
then we should revisit other proposals that add/change syntax. For
example, I think the short syntax for arrays was declined [from 5.3]
mainly because it introduced a new syntax at a time we wanted to
preserve BC:
I find
On Sun, Nov 28, 2010 at 11:42 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Sorry for moving offtopic, but if the PHP syntax is going to change
then we should revisit other proposals that add/change syntax. For
example, I think the short syntax for arrays was declined [from 5.3]
On Sun, Nov 28, 2010 at 12:11 PM, Ferenc Kovacs i...@tyrael.hu wrote:
On Sun, Nov 28, 2010 at 11:42 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Sorry for moving offtopic, but if the PHP syntax is going to change
then we should revisit other proposals that add/change syntax. For
On Sun, 28 Nov 2010 10:42:00 -, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Sorry for moving offtopic, but if the PHP syntax is going to change
then we should revisit other proposals that add/change syntax. For
example, I think the short syntax for arrays was declined [from 5.3]
Hi Again:
On Sat, Nov 27, 2010 at 08:43:40PM -0500, Daniel Convissor wrote:
Not that my vote really counts, but -1. Doing so would eliminate the
helpful ability to grep source code for 'function bar'.
It also will trip up the multitude of PHP IDE's and editors. Plus it
reduces code
Is this going to make it harder for newbies to pick up OOP from a code
readability point of view when they look at other people's and framework's
code? Also my IDE autocompletes it for me (maybe I'm being lazy here) so I
don't see the overhead as being too onerous ( my personal view though)
--
On Sun, 2010-11-28 at 09:02 -0500, Daniel Convissor wrote:
Hi Again:
On Sat, Nov 27, 2010 at 08:43:40PM -0500, Daniel Convissor wrote:
Not that my vote really counts, but -1. Doing so would eliminate the
helpful ability to grep source code for 'function bar'.
I can see this point.
2010/11/27 Johannes Schlüter johan...@schlueters.de:
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
As a plea on behalf of maintenance coders dealing with large, messy
codebases, please,
From what I understand T_FUNCTION would be optional, rather than removed
altogether, is this the case? This would allow those who want to use it the
option of using it and would not break existing code.
--
Ross Masters r...@php.net
http://rossmasters.com/
2010/11/28 David Otton
2010/11/28 Ross Masters r...@php.net
From what I understand T_FUNCTION would be optional, rather than removed
altogether, is this the case? This would allow those who want to use it the
option of using it and would not break existing code.
Yes, exaclty...
--
Regards,
Felipe Pena
On Sat, 27 Nov 2010, Johannes Schlüter wrote:
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
I'm -1 on this one. Besides this being confusing for people who want to
run newer code on older PHP versions; this change does
On Sun, 28 Nov 2010 14:58:13 -, David Otton
phpm...@jawbone.freeserve.co.uk wrote:
2010/11/27 Johannes Schlüter johan...@schlueters.de:
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
On Sun, 28 Nov 2010, Johannes Schlüter wrote:
On Sun, 2010-11-28 at 09:02 -0500, Daniel Convissor wrote:
It also will trip up the multitude of PHP IDE's and editors. Plus it
reduces code portability. All for saving us making a typo and having to
write function?
PHP IDE's don't
Derick Rethans wrote:
On Sat, 27 Nov 2010, Johannes Schlüter wrote:
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
I'm -1 on this one. Besides this being confusing for people who want to
run newer code on older PHP
On 28.11.10 16:14, Gustavo Lopes wrote:
On Sun, 28 Nov 2010 14:58:13 -, David Otton
phpm...@jawbone.freeserve.co.uk wrote:
As a plea on behalf of maintenance coders dealing with large, messy
codebases, please, please don't impact our ability to run 'grep -rs
function functionName *', or
-1
The nuisance of updating IDE, search tools etc doesn't outweigh typing 9
characters less imho.
On Nov 28, 2010 11:53 PM, Martin Jansen mar...@divbyzero.net wrote:
On Sun, Nov 28, 2010 at 10:52 AM, Martin Jansen mar...@divbyzero.netwrote:
On 28.11.10 16:14, Gustavo Lopes wrote:
On Sun, 28 Nov 2010 14:58:13 -, David Otton
phpm...@jawbone.freeserve.co.uk wrote:
As a plea on behalf of maintenance coders dealing with large, messy
codebases, please,
-1
May harm code portability and maintainability, allows intended or accidental
fluctuations in code consistence.
On Sun, Nov 28, 2010 at 6:10 PM, Tjerk Meesters tjerk.meest...@gmail.comwrote:
-1
The nuisance of updating IDE, search tools etc doesn't outweigh typing 9
characters less imho.
Dallas Gutauckis wrote:
Just to be clear, this works on the assumption that we don't know the class
name that the function resides in?
I understand the search argument, but to me it only applies to functions,
not methods. Is anyone arguing for removing the T_FUNCTION requirement on
Add my name to the list of people who prefer more strict than syntactic sugar.
-1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2010/11/28 Ángel González keis...@gmail.com
Dallas Gutauckis wrote:
Just to be clear, this works on the assumption that we don't know the
class
name that the function resides in?
I understand the search argument, but to me it only applies to functions,
not methods. Is anyone arguing
Oh, and I haven't +1 or -1'd.
I write in many languages, some of which don't have method keywords (like
Java: public void doSomething()) and some of which do (like PHP: public
function doSomething()). I trip up whenever I switch between languages, and
it's in both directions.
Ultimately, I feel
Ángel González wrote:
Derick Rethans wrote:
On Sat, 27 Nov 2010, Johannes Schlüter wrote:
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
I'm -1 on this one. Besides this being confusing for people who want to
run newer
On Sunday, November 28, 2010 9:12:34 am Felipe Pena wrote:
2010/11/28 Ross Masters r...@php.net
From what I understand T_FUNCTION would be optional, rather than removed
altogether, is this the case? This would allow those who want to use it
the option of using it and would not break
On Sunday, November 28, 2010 11:24:02 am Dallas Gutauckis wrote:
I understand the concern from above, but I don't agree with it
fundamentally. The kind of practice suggested by this search mechanic tells
me that either there is lack of or little documentation, and lack of or
little
2010/11/28 Dallas Gutauckis dal...@gutauckis.com:
I understand the concern from above, but I don't agree with it
fundamentally. The kind of practice suggested by this search mechanic tells
me that either there is lack of or little documentation, and lack of or
little understanding of the
2010/11/28 Johannes Schlüter johan...@schlueters.de:
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
I'd be -1 at the moment. The patch is certainly fine, but I think this
has the potential
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the parser to prevent conflicts, I therefore propose the
following RFC
Am 27.11.2010 18:40, schrieb Johannes Schlüter:
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
+1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
2010/11/27 Johannes Schlüter johan...@schlueters.de:
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
+1, I've missed being able to skip the function keyword for a while now.
--
regards,
Kalle Sommer Nielsen
2010/11/27 Johannes Schlüter johan...@schlueters.de
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
RFC: http://wiki.php.net/rfc/optional-t-function
Patch:
As long as a modifier (public|private|protected) is still required, +1.
2010/11/27 Johannes Schlüter johan...@schlueters.de:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't
+1
2010/11/27 Johannes Schlüter johan...@schlueters.de
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the
+1 if While technically possible this RFC suggests that the following
shall NOT be valid for keeping the code readable also means that the
patch implements it as well (force the function visibility property
usage).
2010/11/27 Pierrick Charron pierr...@webstart.fr:
+1
2010/11/27 Johannes
On Sat, 2010-11-27 at 19:30 +0100, Pierre Joye wrote:
+1 if While technically possible this RFC suggests that the following
shall NOT be valid for keeping the code readable also means that the
patch implements it as well (force the function visibility property
usage).
The patch follows the
Sorry for moving offtopic, but if the PHP syntax is going to change then we
should revisit other proposals that add/change syntax. For example, I think the
short syntax for arrays was declined [from 5.3] mainly because it introduced a
new syntax at a time we wanted to preserve BC:
-
+1 to being able to omit the function keyword.
2010/11/27 Johannes Schlüter johan...@schlueters.de:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for
2010/11/27 Philip Olson phi...@roshambo.org
Sorry for moving offtopic, but if the PHP syntax is going to change then we
should revisit other proposals that add/change syntax. For example, I think
the short syntax for arrays was declined [from 5.3] mainly because it
introduced a new syntax at
2010/11/27 Johannes Schlüter johan...@schlueters.de
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the parser to
+1 for PHP 7.0. :)
Stuff like this accumulating in trunk kinda makes it more and more
something else than minor release..
--Jani
27.11.2010 19:40, Johannes Schlüter kirjoitti:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier
On 27 nov 2010, at 18:40, Johannes Schlüter johan...@schlueters.de
wrote:
Hi,
every now and then while writing classes I forget to add the
function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is
On Sat, 2010-11-27 at 22:58 +0100, Mike Van Riel wrote:
With this patch I will loose this recognition point and the first
solution that comes to mind is to search for () or arguments. This
sounds rather hackish to me, might I be missing a solution?
The rule is something like
[ T_PUBLIC |
On Sat, 2010-11-27 at 23:14 +0100, Johannes Schlüter wrote:
[ T_PUBLIC | T_PROTECTED | T_PRIVATE | T_STATIC | T_ABSTRACT ] { } T_STRING
( param_list ) { { statement_ist } }
I forgot T_FINAL there.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
@Johannes:
The T_STRING token never contains $, AFAIK all identifiers starting with
$ are instead classed as T_VARIABLE tokens.
So you'd search for the visibility modifier (+ static, etc.) + T_STRING for
methods, and visibility (+ static) + T_VARIABLE for properties.
Martin
2010/11/27 Johannes
Hi:
On Sat, Nov 27, 2010 at 06:40:23PM +0100, Johannes Schlter wrote:
public bar() {
Not that my vote really counts, but -1. Doing so would eliminate the
helpful ability to grep source code for 'function bar'.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O
60 matches
Mail list logo
