Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 it fascinating that a short time ago the short array syntax and other like proposals were unanimously rejected with PHP needs no syntax sugar, everything should be explicit and verbose! and now it's complete reversal - everybody supports syntax sugar, adding new complex syntax and what not. I personally am not sure this thing is worth doing, I never had a problem with typing function but if so many people do, maybe it's OK for a major version 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] RFC: Making T_FUNCTION optional in method declarations
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] mainly because it introduced a new syntax at a time we wanted to preserve BC: I find it fascinating that a short time ago the short array syntax and other like proposals were unanimously rejected with PHP needs no syntax sugar, everything should be explicit and verbose! and now it's complete reversal - everybody supports syntax sugar, adding new complex syntax and what not. I personally am not sure this thing is worth doing, I never had a problem with typing function but if so many people do, maybe it's OK for a major version release. the answer is simple: The people who usually reject the proposals with that reason are: Johannes Schlüter Derick Rethans Richard Lynch Lester Caine and you Stas :) sorry if I wrong somewhere, I've just putting this list from my memory, because I can't search in google or gmail for +1/-1, maybe it would be a good thing, to put together a little statistic from the mailing list to show things like: who are the most active in the votes, who avarage vote by person, etc. ps: I didn't want to offend anybody, so I'm sorry if I did. Tyrael
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 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 it fascinating that a short time ago the short array syntax and other like proposals were unanimously rejected with PHP needs no syntax sugar, everything should be explicit and verbose! and now it's complete reversal - everybody supports syntax sugar, adding new complex syntax and what not. I personally am not sure this thing is worth doing, I never had a problem with typing function but if so many people do, maybe it's OK for a major version release. the answer is simple: The people who usually reject the proposals with that reason are: Johannes Schlüter Derick Rethans Richard Lynch Lester Caine and you Stas :) sorry if I wrong somewhere, I've just putting this list from my memory, because I can't search in google or gmail for +1/-1, maybe it would be a good thing, to put together a little statistic from the mailing list to show things like: who are the most active in the votes, who avarage vote by person, etc. ps: I didn't want to offend anybody, so I'm sorry if I did. Tyrael ahh, I did forget to add Zeev to the list. :) Tyrael
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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] mainly because it introduced a new syntax at a time we wanted to preserve BC: I find it fascinating that a short time ago the short array syntax and other like proposals were unanimously rejected with PHP needs no syntax sugar, everything should be explicit and verbose! and now it's complete reversal - everybody supports syntax sugar, adding new complex syntax and what not. In my opinion, the short array syntax is a completely different matter and we shouldn't be constantly diverting discussions... I personally am not sure this thing is worth doing, I never had a problem with typing function but if so many people do, maybe it's OK for a major version release. It's a completely redundant keyword, which I frequently forget and where I find no expressive power. But I also write a lot of Java, so I might be biased. I'm +0 on this. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 portability. All for saving us making a typo and having to write function? --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 M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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) -- James Butler Sent from my iPhone On 28 Nov 2010, at 14:02, Daniel Convissor dani...@analysisandsolutions.com 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'. 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? --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 M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- 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] RFC: Making T_FUNCTION optional in method declarations
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. 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 understand traits per se, they don't understand other changes per se. Code using new features won't work on older versions, but there's a way to be compatible. Depending on your requirements and likes. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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, please don't impact our ability to run 'grep -rs function functionName *', or hit F8, or whatever your IDE's equivalent is. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 phpm...@jawbone.freeserve.co.uk 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, please don't impact our ability to run 'grep -rs function functionName *', or hit F8, or whatever your IDE's equivalent is. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 nothing but stop you from having to type function. Something that the parser tells you immediately that you have forgotten this. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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. 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 your IDE's equivalent is. IDEs would not be a problem, they would certainly be updated to locate definitions under the new syntax. As to grep, surely you could use another regular expression, perhaps egrep -rs (public|function) functionName or something similar. This seems like a false problem, it's not like it's hard to locate definitions in C or Java codebases... -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 understand traits per se, they don't understand other changes per se. But they understand function. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 versions; this change does nothing but stop you from having to type function. Something that the parser tells you immediately that you have forgotten this. cheers, Derick Join me to the list of people which don't like it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 hit F8, or whatever your IDE's equivalent is. IDEs would not be a problem, they would certainly be updated to locate definitions under the new syntax. As to grep, surely you could use another regular expression, perhaps egrep -rs (public|function) functionName or something similar. At least one would have to use the following expression: (public|protected|private|final|static|function) functionName - Martin, -1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
-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:
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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, please don't impact our ability to run 'grep -rs function functionName *', or hit F8, or whatever your IDE's equivalent is. IDEs would not be a problem, they would certainly be updated to locate definitions under the new syntax. As to grep, surely you could use another regular expression, perhaps egrep -rs (public|function) functionName or something similar. At least one would have to use the following expression: (public|protected|private|final|static|function) functionName 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 functions? - Martin, -1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
-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. On Nov 28, 2010 11:53 PM, Martin Jansen mar...@divbyzero.net wrote:
RE: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
On Thu Nov 25 12:47 PM, Andi Gutmans wrote: I know there have been some high-end apps that have benefited from some custom serializers, etc... (typically platform dependent). I wonder if people here think improvements in these areas would move the needle for the majority of mainstream apps or not. Like people have mentioned, improving (un)serialize speed would be a huge benefit, especially for caching data sets or large objects. From experience, it would seem valuable to have: 1) serialize_text($var) The existing serialize() minus the NULL bytes on private properties. It has been a source problems for developers serializing an object with private properties and storing it in a database (the string may get cutoff). I'm not sure why there's a NULL byte in 'zend_mangle_property_name', instead the char _ could be used to mark a private property in the serialized text. The unserialize could be BC compatible accepting both NULL and _ around a private property. 2) serialize_binary($var) An efficient and compact serialization using techniques from igbinary. A potential problem with igbinary I've noticed is it packs a double as a 64 bit integer. That could be a problem if you serialize on a platform that has an IEEE 754 binary representation and unserialize on a non-IEEE platform but I don't know if php compiles on architectures that are non-IEEE. It could also be interesting to pack integers as varints: http://code.google.com/apis/protocolbuffers/docs/encoding.html#varints http://protobuf-c.googlecode.com/svn/trunk/src/google/protobuf-c/protobuf-c. c That's most likely slower though then what igbinary does with integers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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
functions?
Even knowing the class you are calling, and assuming the common
convention of
one file per class, you may not know in which file is it implemented.
It's annoying
to go into the class, find out it's not there, grep the parent class,
and having to
repeat the process three or four levels up.
Whereas with a unique enough name, grepping the functions get all the
possible
implementations.
Plus, it's not always easy to know in which class to look something :-)
function baz( $param ) {
$param-morlocks();
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 for removing the T_FUNCTION requirement on
functions?
Even knowing the class you are calling, and assuming the common
convention of
one file per class, you may not know in which file is it implemented.
It's annoying
to go into the class, find out it's not there, grep the parent class,
and having to
repeat the process three or four levels up.
Whereas with a unique enough name, grepping the functions get all the
possible
implementations.
Plus, it's not always easy to know in which class to look something :-)
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 code resides thereby
making this argument flawed based solely on the assumption that the majority
of code is (or should be) poorly maintained/documented.
Below is simply bad programming practice in many ways. No validation of type
(neither through type-hinting nor an instanceof check) is done, which is why
the code is so difficult to trace back. Presumably, you'd also have some
form of documentation (PHPDoc, anyone?) that would facilitate the search for
the declaration of that function. Again, that assumes a better programming
practice than is being provided as the example below. One would hope that
someone excluding their function keyword would also be up to date enough
to be validating objects.
function baz( $param ) {
$param-morlocks();
}
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 the keyword is rather useless from a readability
standpoint. The only advantage is for searching (again, moreso on functions
than methods) but still, the argument is there.
2010/11/28 Dallas Gutauckis dal...@gutauckis.com
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 for removing the T_FUNCTION requirement
on
functions?
Even knowing the class you are calling, and assuming the common
convention of
one file per class, you may not know in which file is it implemented.
It's annoying
to go into the class, find out it's not there, grep the parent class,
and having to
repeat the process three or four levels up.
Whereas with a unique enough name, grepping the functions get all the
possible
implementations.
Plus, it's not always easy to know in which class to look something :-)
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 code resides thereby
making this argument flawed based solely on the assumption that the majority
of code is (or should be) poorly maintained/documented.
Below is simply bad programming practice in many ways. No validation of
type (neither through type-hinting nor an instanceof check) is done, which
is why the code is so difficult to trace back. Presumably, you'd also have
some form of documentation (PHPDoc, anyone?) that would facilitate the
search for the declaration of that function. Again, that assumes a better
programming practice than is being provided as the example below. One would
hope that someone excluding their function keyword would also be up to
date enough to be validating objects.
function baz( $param ) {
$param-morlocks();
}
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Á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 code on older PHP versions; this change does nothing but stop you from having to type function. Something that the parser tells you immediately that you have forgotten this. Join me to the list of people which don't like it. And since my name has already been mentioned ;) I see little point in removing what is a very useful 'flag' when trying to understand other peoples code. Yes PHPEclipse will take me to the right definition ( and does all the type hinting that I need! ) but this is still a useful hook when managing code? -- 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] RFC: Making T_FUNCTION optional in method declarations
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 existing code. Yes, exaclty... File me -1. The above argument is oft-used but is not, in fact, a valid argument unless all of the code you work with is your own. The minute you start using 3rd party code (you know, sharing generic libraries in good software engineering and open source etiquette) you are at the whim of whatever syntactic options they chose to use. Optional function, strict typing, exceptions, the list goes on. There is no such thing as an optional language feature if you're working with code you didn't write. Given that, making functional optional makes the language more complex (for me visually scanning it, for an IDE parsing it, etc.) in order to save a few characters. Bad trade-off. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 understanding of the codebase in which the code resides thereby
making this argument flawed based solely on the assumption that the
majority of code is (or should be) poorly maintained/documented.
Below is simply bad programming practice in many ways. No validation of
type (neither through type-hinting nor an instanceof check) is done, which
is why the code is so difficult to trace back. Presumably, you'd also have
some form of documentation (PHPDoc, anyone?) that would facilitate the
search for the declaration of that function. Again, that assumes a better
programming practice than is being provided as the example below. One
would hope that someone excluding their function keyword would also be up
to date enough to be validating objects.
function baz( $param ) {
$param-morlocks();
}
I would like to know how to get to the fantasy world you describe in which all
developers are doing careful type checking and proper DocBlocks on everything.
It sounds like it would be a glorious place to live, if only it could exist.
(I routinely beat people over the head about that in a project with very good
documentation standards, and we still have extremely good developers writing
code that fails both of the above.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 codebase in which the code resides thereby making this argument flawed based solely on the assumption that the majority of code is (or should be) poorly maintained/documented. Yes. Absolutely. The majority of code /is/ poorly maintained and documented. I work with scrappy codebases that have seen dozens of devs over their lifetimes, and this patch removes one of the few certainties - that 'grep function X' is absolutely the fastest way to find the place where X is declared. I'm not an internals guy, so I can't vote, but I will ask you to reconsider this one. 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. My worry is that the last-guy-but-five used the new syntax and now I have to apply a fix to his code. Yeah, I'll find the function on my second/third attempt, but it is an impediment. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hello,
This is my first time using a mailing list, so please bear with me.
Some time back I suggested that PHP should have a property get/set syntax
similar to that of Microsoft's C# language. One of the PHP developers
suggested that if I were serious about it, I should write an RFC. I have
done just that, and I would now like to present my RFC to everyone here in
internals, in order to start a discussion on the topic.
The RFC:
Many modern languages have a special syntax for writing get/set method
pairs. All that PHP currently supports is __get and __set, which while
great for writing generic get/set methods is nearly useless when it comes
to individual properties. Our only other choice is the age old process of
writing custom class methods to make our get/set methods. Not only does
this lack any kind of uniformity, but it also complicates the syntax
($foo-getBar() and $foo-setBar('baz') instead of $foo-bar and
$foo-bar='baz'). I believe that if PHP is going embrace modern
object-oriented design, including encapsulation, than it needs a modern
solution to property getters and setters.
I wont add much more here, but rather let the RFC itself do the talking.
It is fairly well fleshed out, and should explain everything clearly
enough.
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Sunday, November 28, 2010 5:18:40 pm presid...@basnetworks.net wrote:
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
This is a very well-written and well-thought through RFC, Dennis. Nicely
done.
That said, I am not yet convinced. :-)
First of all, I have generally found the Bean-style getter/setter approach to
be a sign of poor encapsulation to begin with. You shouldn't be mucking with
internal elements of an object in the first place, period. More details on
that here:
http://www.garfieldtech.com/blog/property-visibility
However, I do see a potential use here if properties are treated
conceptually as an entirely new concept and not as an indirection layer for
class properties. That would make them more akin to a class that has both
methods and also implements ArrayAccess for properties of the conceptual
object, that may not have anything to do with internal class members.
Viewed from that angle, I would have the following comments:
- I strongly prefer the first syntax over the second. The property keyword
improves readability, and the closing semi-colon is going to be forgotten on a
daily basis. I still forget sometimes when to use it and when not to when
writing Javascript. :-) I cannot speak to the engine complexity involved but
from a PHP-autor point of view I believe the first syntax is much easier to
use.
- The use of identical syntax for class members and properties could create
confusion as to which is which. One could argue that is the point, but only
if we view properties as just an indirection layer around the physical class
members, which as I noted above I believe is a poor architectural design.
There may not be an alternative here, but I mention it for completeness.
- I concur with the RFP's preference for implicit write-only properties
rather than explicit, as it seems more flexible.
- The layering of accessibility keywords I find intriguing, in a mostly good
way. That can offer a great deal of flexibility to control who can do what
when. However, I am concerned about the confusion possible in the following:
public property Hours {
get { return $this-seconds / 3600; }
protected set { $this-seconds = $value * 3600; }
}
The set method is then scoped with two different visibility directives: public
and protected. Which applies? Since both are optional (presumably) I can see
a potential here for confusion, especially if you also start mentioning
keywords like final. This should be made more definitive if possible.
- If interfaces can declare properties (niiice), Traits should be able to
provide them. That provides full parallelism with methods, which I believe
developers will expect.
- I am curious what the performance implication would be. For instance, I've
benchmarked both magic property access (__get()) and ArrayAccess to be around
4 times as slow as accessing a class member.
http://www.garfieldtech.com/blog/benchmarking-magic
Since in essence what is happening here is binding a function to fire when a
class member is accessed (given the identical syntax), I'm concerned that
there would be a similar performance issue. A 4x slower performance cost
would make me avoid properties in favor of class members unless I absolutely
needed them. A 2x or less I could see making more use of.
- Which also brings up an interesting question:
class Foo {
public $a = 1;
protected $b = 2;
public property $a { get { return 3; } }
public property $b { get { return 4; } }
}
$f = new Foo();
print $f-a . PHP_EOL; // Does this print 1 or 3?
print $f-b . PHP_EOL; // Does this print 2 or 4, or error?
I'm sure there's arguments every which way. My preference would be for
properties to always win over class members, followed by the above code sample
being a compile error.
It gets even tricker when you introduce inheritance. If a child class has a
[property|class member] of the same name as a parent's [class member|
property], then what?
That's all I got for now. Once again, nice RFP but still needs some thinking.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
hi,
Great job, very well written proposal.
Quick notice: the readonly keyword work without being used with a
method (or the default getter/setter):
class A {
public readonly propro;
}
The writeonly property (useful from time to time) is not supported by
default but using the custom definitions.
I'm all in favour of having that in PHP. However not in an immediate
future (ie 5.4) but the next major version.
Cheers,
On Mon, Nov 29, 2010 at 12:18 AM, presid...@basnetworks.net wrote:
Hello,
This is my first time using a mailing list, so please bear with me.
Some time back I suggested that PHP should have a property get/set syntax
similar to that of Microsoft's C# language. One of the PHP developers
suggested that if I were serious about it, I should write an RFC. I have
done just that, and I would now like to present my RFC to everyone here in
internals, in order to start a discussion on the topic.
The RFC:
Many modern languages have a special syntax for writing get/set method
pairs. All that PHP currently supports is __get and __set, which while
great for writing generic get/set methods is nearly useless when it comes
to individual properties. Our only other choice is the age old process of
writing custom class methods to make our get/set methods. Not only does
this lack any kind of uniformity, but it also complicates the syntax
($foo-getBar() and $foo-setBar('baz') instead of $foo-bar and
$foo-bar='baz'). I believe that if PHP is going embrace modern
object-oriented design, including encapsulation, than it needs a modern
solution to property getters and setters.
I wont add much more here, but rather let the RFC itself do the talking.
It is fairly well fleshed out, and should explain everything clearly
enough.
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
On 27 November 2010 03:36, Felipe Pena felipe...@gmail.com wrote: I'm here again to presents another proposal, which adds support for instantiating a class and calling its methods and accessing its properties on same command. Thoughts? Great work, Felipe! +1 for the feature; my very weak preference would be for the explicitly bracketed version, but I'd be happy with either. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 to generate a lot of head-scratchers for neophyte coders trying to support code across multiple versions, and would increase our support burden for the benefit of removing a few keystrokes that every remotely experienced PHP developer already has committed to muscle memory. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Sat, 2010-11-27 at 16:26 +, Lester Caine wrote: At the end of the day however it probably has nothing to do with which DVCS is used for master copies. The interoperability now available does mean that we can safely ignore any 'choice' and simply use our own preference locally :) It will be the management of processes which are the main problem, something that is still outstanding anyway currently ... Agreed that most of them are pretty interoperable at this point. ** DISCLAIMER: I am an employee of Canonical, owners of Launchpad ** May I suggest bzr+launchpad as another alternative. MySQL has successfully migrated, and it would offer some real benefits to the process management. * Release and Milestone Management for bugs and specs (Blueprints) * Blueprints tied to milestones/releases (Blueprints == RFC's) * Powerful web based merge proposal management. * Branch aware bug management (bzr commit --fixes lp:1234567 bzr push automatically attaches the branch to the bug) I've not used git or hg much at all, but bzr has always satisfied my needs for DVCS, and has recently gotten much faster and more space efficient than it was in the past. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi,
I like the idea of the property get/set syntax, but in my opinion it
doesn't figure with PHP's syntax, because it breaks the readability. The
problem for me is the nesting of the inner set and get. How do you
document these syntax.
/**
*
*/
public $name {
/**
*
*/
get {
return $this-name;
}
/**
*
*/
set {
$this-name = htmlentities($value);
$this-name = strip_tags($this-name);
}
};
What I also miss is the lack of type hinting. As I see it, it isn't
possible with this syntax.
I would prefer the syntax from ActionScript. This is more like the
normal PHP function syntax with an additional set or get keyword.
/**
*
*/
public function set name(string $name) {
$this-name = htmlentities($name);
$this-name = strip_tags($this-name);
}
/**
*
*/
public function get name($name) {
return $this-name;
}
Greetings,
Christian
On Sun, 28 Nov 2010 18:18:40 -0500, presid...@basnetworks.net wrote:
Hello,
This is my first time using a mailing list, so please bear with me.
Some time back I suggested that PHP should have a property get/set
syntax
similar to that of Microsoft's C# language. One of the PHP
developers
suggested that if I were serious about it, I should write an RFC. I
have
done just that, and I would now like to present my RFC to everyone
here in
internals, in order to start a discussion on the topic.
The RFC:
Many modern languages have a special syntax for writing get/set
method
pairs. All that PHP currently supports is __get and __set, which
while
great for writing generic get/set methods is nearly useless when it
comes
to individual properties. Our only other choice is the age old
process of
writing custom class methods to make our get/set methods. Not only
does
this lack any kind of uniformity, but it also complicates the syntax
($foo-getBar() and $foo-setBar('baz') instead of $foo-bar and
$foo-bar='baz'). I believe that if PHP is going embrace modern
object-oriented design, including encapsulation, than it needs a
modern
solution to property getters and setters.
I wont add much more here, but rather let the RFC itself do the
talking.
It is fairly well fleshed out, and should explain everything clearly
enough.
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
Hi Felipe,
I'm wondered it works out of the box with so small patches :)
However, both patches introduce new parser conflicts and it would be
grate to avoid them.
Also the patches need to be checked for memory leaks in case of
exceptions thrown from constructor and chained function(s).
It also probably makes sense to add array deference chaining e.g. new
Foo()[] (just for language consistency).
Thanks. Dmitry.
On 11/26/2010 10:36 PM, Felipe Pena wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
