# PHP6 OOP compiler feature question / request

- Thread: https://externals.io/message/23231
- Original archive: https://news-web.php.net/php.internals/23231
- Started by Ralph Schindler on 2006-05-10T17:28:40+00:00
- Messages: 11
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #23231 — Ralph Schindler — 2006-05-10T17:28:40+00:00

URL: https://externals.io/message/23231#23231

Architectural restrictions aside, is it far off to ask if something like 
this could be possible in PHP6:

<?

class TestReservedKeywordMethods
{
     public $value = "2";

     public function isset()
     {
         if (is_null($this->value))
             return false;
         else
             return true;
     }

     public function unset()
     {
         $this->value = 0;
     }

}

$test = new TestReservedKeywordMethods();
$test->isset();
$test->unset();

?

---

## #23232 — Antony Dovgal — 2006-05-10T19:26:45+00:00

URL: https://externals.io/message/23231#23232 · In reply to: #23231

__isset() and __unset() methods are what you're looking for.
They are available since 5.1.0.

See http://www.php.net/manual/en/language.oop5.overloading.php


> Architectural restrictions aside, is it far off to ask if something like 
> this could be possible in PHP6:
> 
> <?
> 
> class TestReservedKeywordMethods
> {
>      public $value = "2";
> 
>      public function isset()
>      {
>          if (is_null($this->value))
>              return false;
>          else
>              return true;
>      }
> 
>      public function unset()
>      {
>          $this->value = 0;
>      }
> 
> }
> 
> $test = new TestReservedKeywordMethods();
> $test->isset();
> $test->unset();
> 
> ?>
> 


-- 
Wbr, 
Antony Dovgal

---

## #23235 — Jochem Maas — 2006-05-10T23:15:03+00:00

URL: https://externals.io/message/23231#23235 · In reply to: #23232

Antony, I believe Ralph was using isset() and unset() purely
as arbitrary examples, e.g:

class TestReservedKeywordMethods
{
	function unset() { echo "unset<br />"; }
	function echo()  { echo "echo<br />";  }
	function empty() { echo "empty<br />"; }
}

$test = new TestReservedKeywordMethods();
$test->unset();
$test->echo();
$test->empty();

PS: the underlying example does work, which gives me the feeling that
it not so much an architechural limitation but rather a performance issue
with regard to doing extra checks as to the context of an encoutered
 `T_UNSET` (for example) to determine whether it's okay, but I'm guessing
really - (and it's probably is not exactly what Ralph is looking for):

class TestReservedKeywordMethods
{
	function __call($m) { echo "$m<br />"; }
}

$test = new TestReservedKeywordMethods();
$test->unset();
$test->echo();
$test->empty();



Antony Dovgal wrote:
> 
> __isset() and __unset() methods are what you're looking for.
> They are available since 5.1.0.
> 
> See http://www.php.net/manual/en/language.oop5.overloading.php
> 
> 
> 
> > […]

---

## #23254 — Ralph Schindler — 2006-05-11T17:14:33+00:00

URL: https://externals.io/message/23231#23254 · In reply to: #23235

Precisely.  The point I was trying to make is that there should be fewer 
restrictions on method names of classes so that developers that are 
maintaining some distributable classes can keep the API clean.  I've 
found myself in a situation where instead of using a method call 
isset(), I must use something like has().. and instead of unset(), I use 
remove().  All the while, when I overload the __isset() and __unset() 
methods, they actually forward the request to has() and remove().

I can think of several classes where the common sense method is a keyword:

$session->isset($variable);
$session->unset($variable);
$trash->empty();
$long_hallway->echo();
$stage->exit();
$baseball_player->catch();
$baseball_player->throw();
$game_of_life_member->die();
$wood->break();
$vegetarian->food->steak->try();
$lawyer->case->try(); // double fault ;)

Now I'm getting silly, but that was what my point was ;)

-ralph



Jochem Maas wrote:
> Antony, I believe Ralph was using isset() and unset() purely
> as arbitrary examples, e.g:
> 
> class TestReservedKeywordMethods
> {
>     function unset() { echo "unset<br />"; }
>     function echo()  { echo "echo<br />";  }
>     function empty() { echo "empty<br />"; }
> }
> 
> $test = new TestReservedKeywordMethods();
> $test->unset();
> $test->echo();
> $test->empty();
> 
> PS: the underlying example does work, which gives me the feeling that
> it not so much an architechural limitation but rather a performance issue
> with regard to doing extra checks as to the context of an encoutered
> `T_UNSET` (for example) to determine whether it's okay, but I'm guessing
> really - (and it's probably is not exactly what Ralph is looking for):
> 
> class TestReservedKeywordMethods
> {
>     function __call($m) { echo "$m<br />"; }
> }
> 
> $test = new TestReservedKeywordMethods();
> $test->unset();
> $test->echo();
> $test->empty();
> 
> 
> 
> Antony Dovgal wrote:
> > […]

---

## #23264 — Jasper Bryant-Greene — 2006-05-11T19:34:44+00:00

URL: https://externals.io/message/23231#23264 · In reply to: #23254

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Just to add my 2c, I am currently trying to migrate a legacy PHP4
application to PHP5, and one of the huge hurdles is a set of classes
representing a group of tasks, each class having a method called try().
These classes are used in over 100,000 lines of other code.

It seems to me like an artificial limitation (i.e. it should be simple
to tell which sense the keyword is meant in), but I'd like to hear from
a developer on it.

Jasper

Ralph Schindler wrote:
> Precisely.  The point I was trying to make is that there should be fewer
> restrictions on method names of classes so that developers that are
> maintaining some distributable classes can keep the API clean.  I've
> found myself in a situation where instead of using a method call
> isset(), I must use something like has().. and instead of unset(), I use
> remove().  All the while, when I overload the __isset() and __unset()
> methods, they actually forward the request to has() and remove().
> 
> I can think of several classes where the common sense method is a keyword:
> 
> $session->isset($variable);
> $session->unset($variable);
> $trash->empty();
> $long_hallway->echo();
> $stage->exit();
> $baseball_player->catch();
> $baseball_player->throw();
> $game_of_life_member->die();
> $wood->break();
> $vegetarian->food->steak->try();
> $lawyer->case->try(); // double fault ;)
> 
> Now I'm getting silly, but that was what my point was ;)
> 
> -ralph
> 
> 
> 
> Jochem Maas wrote:
> > […]
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFEY5HUFfAeHhDzT4gRA5BxAKD3exjFKLx5uQvNK0LS0w0jNiO5/QCgn/d0
Mtb5Nv3ysjhLQR3+69O0dFI=
=HMHb
-----END PGP SIGNATURE

---

## #23268 — Pierre — 2006-05-11T19:37:37+00:00

URL: https://externals.io/message/23231#23268 · In reply to: #23264

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> Just to add my 2c, I am currently trying to migrate a legacy PHP4
> application to PHP5

In case you miss it, this discussion is about breakages within the
same major version.

--Pierre

---

## #23269 — Jasper Bryant-Greene — 2006-05-11T19:46:14+00:00

URL: https://externals.io/message/23231#23269 · In reply to: #23268

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Pierre wrote:
> 
> > […]
> 
> In case you miss it, this discussion is about breakages within the
> same major version.

Really? Have keywords been supported as method names in a previous PHP5
release?

In any event, I'm just trying to indicate that others may also face
issues if they have PHP4 apps with these sorts of keywords in them.

Jasper
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFEY5SGFfAeHhDzT4gRAzVSAKCM5Y2ZMVqOWMfMy1wBThWDyqD7owCcDUbW
1a8Daw8hVj0poJ8o8A9WlHQ=
=KYkl
-----END PGP SIGNATURE

---

## #23271 — Sean Coates — 2006-05-11T19:56:04+00:00

URL: https://externals.io/message/23231#23271 · In reply to: #23269

> In any event, I'm just trying to indicate that others may also face
> issues if they have PHP4 apps with these sorts of keywords in them.

"try" has been a reserved word (documented) since Fri Oct 1 08:07:16
2004 UTC:
http://cvs.php.net/viewcvs.cgi/phpdoc/en/appendices/reserved.xml?view=diff&r1=1.48&r2=1.49

See:
http://php.net/manual/en/reserved.php
(which admittedly needs work)

"You cannot use any of the following words as constants, class names,
function or method names."

I do understand the original question, and I supposed it IS technically
possible to determine the context of a `T_TRY` token, but nonetheless,
it's bad practice to have functions named the same as reserved words
(even where allowed).

S

---

## #23272 — Jasper Bryant-Greene — 2006-05-11T20:00:42+00:00

URL: https://externals.io/message/23231#23272 · In reply to: #23271

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Sean Coates wrote:
> > […]
> 
> "try" has been a reserved word (documented) since Fri Oct 1 08:07:16
> 2004 UTC:
> http://cvs.php.net/viewcvs.cgi/phpdoc/en/appendices/reserved.xml?view=diff&r1=1.48&r2=1.49
> 
> See:
> http://php.net/manual/en/reserved.php
> (which admittedly needs work)
> 
> "You cannot use any of the following words as constants, class names,
> function or method names."
> 
> I do understand the original question, and I supposed it IS technically
> possible to determine the context of a `T_TRY` token, but nonetheless,
> it's bad practice to have functions named the same as reserved words
> (even where allowed).

This application was developed in 2001, at which point 'try' was not a
keyword and the original developers of the app had no idea it was to
become one.

I'm sure there are many others out there in the same boat.

Jasper
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFEY5fqFfAeHhDzT4gRA++8AKCSDqC+dORY7YD+G8ouxboGwXtigwCdGIrF
H6Yz6oBt9QqeKd5Z7d33DKg=
=zcoJ
-----END PGP SIGNATURE

---

## #23273 — Ralph Schindler — 2006-05-11T20:13:34+00:00

URL: https://externals.io/message/23231#23273 · In reply to: #23271

> In case you miss it, this discussion is about breakages within the
 > same major version.

I am talking strictly from a Major Release standpoint, which is why I 
titled it PHP6 compiler features...

...

My understanding is that this type of change would be slightly massive 
undertaking to the compiler.

Essentially, its adding a context switch in the parser to allow certain 
words as methods within a class ONLY.  An error should be thrown if 
someone is trying to redefine isset() in the global namespace.  My 
reasoning being is that $baseball_player->catch() is a completely 
different context than try {} catch () {}.

 > possible to determine the context of a `T_TRY` token, but nonetheless,
 > it's bad practice to have functions named the same as reserved words

Thats a matter of opinion.  I think its bad practice to think up a 
method name that is less concise in naming than what should have been 
allowed.

-ralph

---

## #23346 — Wez Furlong — 2006-05-14T21:09:46+00:00

URL: https://externals.io/message/23231#23346 · In reply to: #23273

> > […]
>
> Thats a matter of opinion.  I think its bad practice to think up a
> method name that is less concise in naming than what should have been
> allowed.

The fact of the matter is that reserved means reserved and that if you
use those identifiers and you app breaks on newer versions of PHP, you
get to keep all the pieces.

--Wez.