[RFC] Keywords as identifiers

*Should have been !== null

"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.comwrote:

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

Am 18.09.2013 um 09:28 schrieb "David Neilsen" david@pan.co.nz:

"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.comwrote:

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

Thank you all for your feedback; I was effectively missing a few concrete examples.

I now added some examples.

Bob Weinand