Re: Reflection API: Add ::getFullName() method.

From: Date: Mon, 11 Dec 2017 09:16:22 +0000
Subject: Re: Reflection API: Add ::getFullName() method.
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-101317@lists.php.net to get a copy of this message
On Mon, Dec 11, 2017 at 10:03 AM, Andreas Hennings <andreas@dqxtech.net> wrote: > On 11 December 2017 at 09:16, Marco Pivetta <ocramius@gmail.com> wrote: > > If you really want to expose a symbol's FQN, > > Just to clarify: For me, "FQN" means "fully-qualified name", which > begins with "\\". > This is specifically not what I propose here. I want the name without > the leading namespace separator. > So maybe "getFullName()" is misleading. > A FQN does not start with \. In strings, you always use the FQN > > > I suggest exposing the internal > > name as per (array) cast semantics. > > This distinction is not needed here. > The semantics for array keys in array-to-object casting are to > distinguish overshadowed private properties from parent classes. > This is because values for these properties can coexist within one object. > > E.g. > > class B { > private $x = 'b'; > } > > class C extends B { > private $x = 'c'; > } > > var_export((array)(new C)); > > > Output: https://3v4l.org/0QE3s > > array ( > '' . "\0" . 'C' . "\0" . 'x' => > 'c', > '' . "\0" . 'B' . "\0" . 'x' => > 'b', > ) > > > For ReflectionClass->getProperties() and ->getProperty($name) only > gives us the version of each property that is visible on the top > level. > > https://3v4l.org/LWWSf > > E.g. > > $obj = new > > (new \ReflectionClass(C::class)->getProperty('x') > That still makes merging property definitions extremely messy - as a heavy reflection user, I don't see the value in such an API then, besides display (var_dump()) purposes... > > > namespace A { > > class B { > > public $c; > > private $d; > > private $e; > > } > > } > > > > That would be: > > > > "A\B#\$c" > > "A\B#\0*\0\$d" > > "A\B#\0A\\B\0\$e" > > > > Obviously, the \0 is horrible and can probably be > > improved: depends on > > whether the API is intended for human or machine consumption. If it is > > machine consumption, strings are the wrong approach anyway. > > Machine or human? > One goal is that these names can be used as array keys or unique > identifiers whenever we deal with a collection of reflectors of mixed > type. > At the same time, the name is designed to be very close to what is > printed in exception messages, @see doc comment, etc. > In this case, I don't see a conflict between human-readable and > machine-readable. > > Maybe when you say "machine consumption" you are thinking of something > else? > Machine consumption would be VOs, not strings ;-) > > > I'd also add that this would be (fucking finally!) a good way to fix > PHP's > > documentation horrible usage of :: for both instance and > > static > members. > > Ok, tbh, so far I thought of using the same "::" for both :) > So for all properties it would be Cat::$color. > > Maybe instead we could do Cat->color for instance members? > I have been using # for a while, but I can adapt as long as the problem is being fixed at some point in time :P Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

« previous php.internals (#101317) next »