Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101316
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADyq6sKLc=7tUt_bffXsmvvc2nBBp4mHiwzR_F=O3y85vUJCdA@mail.gmail.com>
References: <CAH0Uv3Hf_uTgHo5bg5x_A5DUfkB7bjSXzPZ5yXGS3JDdDJWW+A@mail.gmail.com>
 <CADyq6sKLc=7tUt_bffXsmvvc2nBBp4mHiwzR_F=O3y85vUJCdA@mail.gmail.com>
Date: Mon, 11 Dec 2017 10:03:40 +0100
Message-ID: <CAH0Uv3ECNFAUN_mjaG3dacwoK617HzLmFJOnwxJSN5SP8POyVQ@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Reflection API: Add ::getFullName() method.
From: andreas@dqxtech.net (Andreas Hennings)

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.

> 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')



>
> 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?


>
> 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?