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
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 {
/**
*
*/
ge
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 :
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
On 27 November 2010 03:36, Felipe Pena 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
b
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 definition
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
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
don
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
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
-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
35 matches
Mail list logo
