Re: [RFC] Keywords as identifiers

From: Date: Wed, 18 Sep 2013 07:28:40 +0000
Subject: Re: [RFC] Keywords as identifiers
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
*Should have been !== null


On Wed, Sep 18, 2013 at 7:27 PM, David Neilsen <[email protected]> wrote:

> "missing any real-world examples of why it might be useful"
>
> One thing the I have run across in making my libraries, is the not being
> able to call a function default.
>
> I use the chainable getter/setter in one syntax a lot (a la jQuery). Hence
> when I have a class with a property named default, and can not make a
> method in that sense. It makes my API inconsistent as I have to use a
> getDefault, setDefault, when every other method is a single word.
>
> Such as:
>
> class Foo {
>     public $default;
>     public function default($default = null) {
>         if ($default === null) {
>             return $this->default;
>         }
>         $this->default = $default;
>         return $this;
>     }
> }
>
> This might not be the prefered way to write methods, but I don't see why
> the language should restrict me from doing so because the word default is
> used in a different context.
>
>
> On Wed, Sep 18, 2013 at 5:19 PM, Matthew Leverton <[email protected]>wrote:
>
>> On Tue, Sep 17, 2013 at 7:50 PM, Stuart Langley <[email protected]>
>> wrote:
>> > To be honest, looking at the example in the RFC, being able to define a
>> > member function 'new' on a class that completely changes the semantics
>> of
>> > the new operator is a great example of why you would not want this
>> feature.
>> >
>> It doesn't change anything because $foo->new() has no intrinsic
>> meaning in PHP. And I don't think the argument "the programmer might
>> do something stupid" ever holds much weight as a no vote against
>> anything. If somebody wants to create a confusing misnomer, he doesn't
>> need this proposed feature to do so.
>>
>> But I agree that the RFC is missing any real-world examples of why it
>> might be useful, and that any new language feature should have
>> real-world benefits. Hopefully some more compelling reasons will be
>> added to the RFC.
>>
>> Here's something that I've personally done with much shame:
>>
>> class Where
>> {
>>   private function _or($lhs, $op = null, $rhs = null)
>>   {
>>   }
>>
>>   public function __call($func_name, $args)
>>   {
>>     if ($func_name == 'or')
>>       return call_user_func_array([$this, '_or'], $args);
>>   }
>> }
>>
>> $query->where('foo', '=', 1)->or('bar', '=',
>> 2);
>>
>> Imagine that $query->where() returns a Where object. I really want an
>> "or" method because it make things concise & readable, but this is not
>> allowed. So I override the __call method to add such functionality,
>> which adds useless overhead.
>>
>> There are a few keywords, such as list and unset, that I often wish I
>> could use in PHP. So in terms of readability, I think any sane
>> programmer would use this proposed functionality for good...
>>
>> --
>> Matthew Leverton
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>


Thread (15 messages)

« previous php.internals (#69179) next »