Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69178
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain panmedia.co.nz designates 209.85.212.169 as permitted sender)
MIME-Version: 1.0
Sender: david@panmedia.co.nz
In-Reply-To: <CAN=kQJdrbeMFQ7VjmFenUYE+sdy7PH2j9=GXaGUKNq8rKDXBZg@mail.gmail.com>
References: <BLU0-SMTP3894352C042C2594271266FE2260@phx.gbl>
	<CALFY5Zzn+KKb_K0hRptKuz5aaL5PqrQ_Y7kP8h=m617QM-0=qQ@mail.gmail.com>
	<CAN=kQJdrbeMFQ7VjmFenUYE+sdy7PH2j9=GXaGUKNq8rKDXBZg@mail.gmail.com>
Date: Wed, 18 Sep 2013 19:27:47 +1200
Message-ID: <CAJezvQUAbrFxt+gEgumQR4kyuY22csunzhVM=wPe5xO3W7htbg@mail.gmail.com>
To: Matthew Leverton <leverton@gmail.com>
Cc: Stuart Langley <slangley@google.com>, Bob Weinand <bobwei9@hotmail.com>, 
	Developers PHP Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e011779b5c03fb904e6a35f9d
Subject: Re: [PHP-DEV] [RFC] Keywords as identifiers
From: david@pan.co.nz (David Neilsen)

--089e011779b5c03fb904e6a35f9d
Content-Type: text/plain; charset=ISO-8859-1

"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 <leverton@gmail.com>wrote:

> On Tue, Sep 17, 2013 at 7:50 PM, Stuart Langley <slangley@google.com>
> 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
>
>

--089e011779b5c03fb904e6a35f9d--