-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 p
On Thu, Dec 2, 2010 at 17:07, 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
>>
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 - PH
2010/12/2 Peter Beverloo :
> On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT wrote:
>> 2010/12/2 André Rømcke :
>>> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT
>>> wrote:
Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
introducing the possible omission of T_FUNCTION?
>>>
On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT wrote:
> 2010/12/2 André Rømcke :
>> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT
>> 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
2010/12/2 André Rømcke :
> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT
> 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 at it? Is 'var'
> hinderi
How about deprecation then?
On Thu, Dec 2, 2010 at 3:58 AM, André Rømcke wrote:
> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT >wrote:
>
> > 2010/11/30 Kalle Sommer Nielsen :
> > > Hi
> > >
> > > 2010/11/30 Patrick ALLAERT :
> > >> With this patch, something looks inconsistent to me:
> > >>
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT wrote:
> 2010/11/30 Kalle Sommer Nielsen :
> > Hi
> >
> > 2010/11/30 Patrick ALLAERT :
> >> With this patch, something looks inconsistent to me:
> >> Both properties and methods have a visibility
> >> (public|protected|private) and a keyword: "var"
I toast to that. Get rid of T_VAR already.
Regards,
David
On Thu, Dec 2, 2010 at 3:34 AM, Patrick ALLAERT wrote:
> 2010/11/30 Kalle Sommer Nielsen :
> > Hi
> >
> > 2010/11/30 Patrick ALLAERT :
> >> With this patch, something looks inconsistent to me:
> >> Both properties and methods have a visi
2010/11/30 Kalle Sommer Nielsen :
> Hi
>
> 2010/11/30 Patrick ALLAERT :
>> 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 "privat
Hi, first time on the lists, guess I'm from userlando too,
+1 for readability, all I ever really look at are "( ... ){" at the end of
the line so I personally don't think it affects readability. Also, this is
the way its done in other languages and I have always found the function
keyword unnecess
Hi
2010/11/30 Patrick ALLAERT :
> 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 error but "pr
2010/11/27 Johannes Schlüter :
> 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 confli
2010/11/27 Johannes Schlüter
>
> 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 confl
+1 for next major, but not for middle point release. =)
2010/11/29 Pierre Joye :
> my +1 for new major version only, btw :)
>
> 2010/11/27 Pierre Joye :
>> +1 if "While technically possible this RFC suggests that the following
>> shall NOT be valid for keeping the code readable " also means that t
my +1 for new major version only, btw :)
2010/11/27 Pierre Joye :
> +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).
Cheer
2010/11/28 Johannes Schlüter :
> 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 to generate a lot of
2010/11/28 Dallas Gutauckis :
> 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 codebase in which the
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 underst
On Sunday, November 28, 2010 9:12:34 am Felipe Pena wrote:
> 2010/11/28 Ross Masters
>
> > 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 c
Á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"
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 t
2010/11/28 Ángel González
> 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 rem
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
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
> func
-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 wrote:
> -1
>
> The nuisance of updating IDE, search tools etc doesn't outweigh typing 9
> characters less imho.
> On Nov 28, 2010 11:
On Sun, Nov 28, 2010 at 10:52 AM, Martin Jansen wrote:
> On 28.11.10 16:14, Gustavo Lopes wrote:
> > On Sun, 28 Nov 2010 14:58:13 -, David Otton
> > wrote:
> >> As a plea on behalf of maintenance coders dealing with large, messy
> >> codebases, please, please don't impact our ability to run '
-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" wrote:
On 28.11.10 16:14, Gustavo Lopes wrote:
> On Sun, 28 Nov 2010 14:58:13 -, David Otton
> 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 hit F8, or whatever you
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
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'
On Sun, 28 Nov 2010 14:58:13 -, David Otton
wrote:
2010/11/27 Johannes Schlüter :
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 w
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 d
2010/11/28 Ross Masters
> 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
>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
http://rossmasters.com/
2010/11/28 David Otton
> 2010/11/27 Johannes Schl
2010/11/27 Johannes Schlüter :
> 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, please don't impact o
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 p
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)
--
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 por
On Sun, 28 Nov 2010 10:42:00 -, Stas Malyshev
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]
mainly because it introduc
On Sun, Nov 28, 2010 at 12:11 PM, Ferenc Kovacs wrote:
>
>
> On Sun, Nov 28, 2010 at 11:42 AM, Stas Malyshev 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 th
On Sun, Nov 28, 2010 at 11:42 AM, Stas Malyshev 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]
>> mainly because it
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 i
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
@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 Johan
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,
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 27 nov 2010, at 18:40, 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 par
+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
2010/11/27 Johannes Schlüter
> 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 confli
2010/11/27 Philip Olson
> 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
+1 to being able to omit the function keyword.
2010/11/27 Johannes Schlüter :
> 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
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:
- http://wik
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
+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 :
> +1
>
> 2010/11/27 Johannes Schlüter
>
>> Hi,
>>
+1
2010/11/27 Johannes Schlüter
> 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 co
As long as a modifier (public|private|protected) is still required, +1.
2010/11/27 Johannes Schlüter :
> 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 requir
2010/11/27 Johannes Schlüter
> 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: http://schlueters.de/~johannes/php/zend_optional
2010/11/27 Johannes Schlüter :
> 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
ka...@php.net
--
PHP Internals
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/
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
61 matches
Mail list logo
