Bug #54441 [Asn->Csd]: Traits - Visibility on alias names
| From: | gron@php.net | Date: | Fri, 18 Nov 2011 13:53:48 +0000 |
| Subject: | Bug #54441 [Asn->Csd]: Traits - Visibility on alias names | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-165328@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=54441&edit=1
ID: 54441
Updated by: gron@php.net
Reported by: php-svn at helio dot arq dot br
Summary: Traits - Visibility on alias names
-Status: Assigned
+Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: trunk-SVN-2011-04-01 (snap)
Assigned To: gron
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Fixed in SVN rev 319483.
These kind of two-step declarations are now disallowed and cause a compilation
error.
The reason is that it invites inconsistencies like:
Foo::lol as dontKnow public;
dontKnow as protected;
Possible inconsistencies, as well as the 'dont repeat yourself' principle are
the reasons to disallow it completely.
Previous Comments:
------------------------------------------------------------------------
[2011-11-18 13:48:56] gron@php.net
Automatic comment from SVN on behalf of gron
Revision: http://svn.php.net/viewvc/?view=revision&revision=319483
Log: Fixes Bug #54441 (Handling of changing modifiers on a trait alias)
# this now results also in a compilation error, since it would open the door for inconsistencies,
and violates the DRY principle.
------------------------------------------------------------------------
[2011-07-23 08:01:57] gron@php.net
Hm, today I feel like it is not a good idea to allow
use Foo {
Foo::lol as dontKnow;
dontKnow as protected;
}
Because we will end up with chains like this:
use Foo {
Foo::lol as dontKnow;
dontKnow as foo;
foo as bar;
bar as baz;
}
And I do not see the use case for it, while I see readability problems.
This is all equivalent to:
use Foo {
Foo::lol as dontKnow;
Foo::lol as foo;
Foo::lol as bar;
Foo::lol as baz;
}
Which IMHO is a lot clearer. Every level of indirection is another level of added complexity, and I
do not see a relevant use case at the moment.
So, I will regard this as something that should not work.
Not sure yet how to design it properly. Will look at it.
------------------------------------------------------------------------
[2011-07-22 13:33:19] me at mikestowe dot com
class Boo {
use Foo {
Foo::lol as dontKnow;
dontKnow as protected;
}
}
To me this would do the following:
Use "Foo", set "Foo:lol" as "dontKnow", and then set
"dontKnow" as "protected"
Meaning that I should be able to call $boo->lol, $boo->dontKnow, or $boo->protected to
accomplish the same thing.
Otherwise it should throw a method does not exist error if the "as" is supposed to rename
the function.
------------------------------------------------------------------------
[2011-04-03 15:30:16] php at stefan-marr dot de
Interesting question.
I suppose it could be legal (but obviously it is currently not implemented).
It looks kind of ugly to me, since it is less concise.
But well, all the traits use definitions should be declarative and orderless, so
if it is possible to do something with two separate declarations then people
might expect that it works.
Not sure whether we want that...
But anyway, a good catch, thanks.
Stefan
------------------------------------------------------------------------
[2011-04-02 18:14:36] felipe@php.net
According to the actual grammar and implementation, the right way to do this is using:
Foo::lol as protected dontKnow;
Stefan Marr, is supposed to work the code as the bug reporter tried it?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54441
--
Edit this bug report at https://bugs.php.net/bug.php?id=54441&edit=1