Edit report at https://bugs.php.net/bug.php?id=54441&edit=1

 ID:                 54441
 Updated by:         g...@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] g...@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] g...@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] fel...@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

Reply via email to