What's the use-case for creating a userland `ReflectionType` instance,
besides mocking the reflection API itself?
Consider that the subclassing in userland already provides an easy way to
perform these operations (although ugly):
https://github.com/Roave/BetterReflection/blob/2.0.1/src/Reflection/A
>
> Documentation tools shouldn't run the code IMO, that means they won't have
> access to that feature.
By "documentation tools" do you mean libraries like phpDocumentor?
You are right, those need to parse anyway, they cannot use reflection API.
But tools for annotation discovery may want to use
Indeed that already exists at
https://github.com/Roave/BetterReflection/blob/2.0.1/docs/features.md#analysing-types-from-docblocks
- relatively new lib, so it probably didn't get noticed upfront in here.
It would probably be a good idea to address the fact that the current
reflection API causes au
Andreas Hennings schrieb am Mo., 11. Dez. 2017, 01:39:
> TLDR:
> I propose to introduce a new class \ReflectionContext (or perhaps
> \ReflectionScope?), to give information about imported aliases and the
> namespace.
>
>
> ## Background / motivation
>
> Some libraries that parse doc comment annot
Currently there is no (documented) way to directly create a
\ReflectionType object.
The class has no documented constructor.
I propose that static factory methods shall be added for this purpose.
This will be useful for code that wants to dynamically create and pass
around reflection type objects
On 11 December 2017 at 04:03, Andreas Hennings wrote:
> So far this proposal only discusses reflections of PHP declarations / symbols.
>
> What would we do for e.g. ReflectionObject?
> Return the spl_object_hash()?
> Or return the hash of the instantiated class?
> Or a hash of the serialized objec
So far this proposal only discusses reflections of PHP declarations / symbols.
What would we do for e.g. ReflectionObject?
Return the spl_object_hash()?
Or return the hash of the instantiated class?
Or a hash of the serialized object?
We need to return something, because ReflectionObject extends R
I propose a new method ::getFullName() for all methods that implement
\Reflector.
(I would add it to the \Reflector interface, but this would be a BC break.)
The full name would be, depending on the type:
function: "str_replace()", "Acme\foo()".
class: "Acme\Animal\Cat", "stdClass".
method: "Acme
On Wed, Dec 6, 2017 at 12:49 PM, Nikita Popov wrote:
> Hi internals,
>
> I'd like propose optional support for explicitly marking by-reference
> argument passing at the call-site, in addition to the declaration-site:
>
> https://wiki.php.net/rfc/explicit_send_by_ref
>
> In short, while current
I propose to add a new method ::getHash() to reflection API classes.
Such that:
Two reflectors return the same hash, if and only if:
1. the reflected items have the same type (class, method, parameter etc), AND.
2. the reflected items have the same names, AND.
3. the reflected items have the sam
## Background / motivation
Currently a number of reflection classes have a method ->getNamespaceName().
The namespace comes in a format that is not straightforward to work with.
It requires the root namespace to be treated in a special way.
$namespace = $relfClass->getNamespaceName();
$shortname
TLDR:
I propose to introduce a new class \ReflectionContext (or perhaps
\ReflectionScope?), to give information about imported aliases and the
namespace.
## Background / motivation
Some libraries that parse doc comment annotations, e.g. phpDocumentor,
need to know the class aliases and the names
Oh wow, feature request already exists, with a link to this thread.
On 10 December 2017 at 22:41, Andreas Hennings wrote:
>
>
> On 7 December 2017 at 03:04, Stanislav Malyshev
> wrote:
>>
>> All this to achieve no other benefit but a purely cosmetic one which a
>> good IDE could easily deliver
On 7 December 2017 at 03:04, Stanislav Malyshev wrote:
>
> All this to achieve no other benefit but a purely cosmetic one which a
> good IDE could easily deliver to you for free without changing language
> syntax. I do not think it is worth it.
>
I agree with Stanislav, this should be the IDE's j
Hi folks
I have the idea to improve the PHP source by using static analyzers. The
first one that I would use for this is clang's scan-build and the second
one is Coverity. The idea is not new, because I can find people talking
about this on the internals mailing list, but that is all at least 4-6
Hi,
On Mi, 2017-12-06 at 20:49 +0100, Nikita Popov wrote:
> Hi internals,
>
> I'd like propose optional support for explicitly marking by-reference
> argument passing at the call-site, in addition to the declaration-
> site:
>
> https://wiki.php.net/rfc/explicit_send_by_ref
>
I would rathe
> -Original Message> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Sunday, December 10, 2017 1:05 PM
> To: Sara Golemon
> Cc: Andreas Hennings ; PHP internals
>
> Subject: Re: [PHP-DEV] instanceof survives non-object variables, but crashes
> on
> non-object constants.
>
> >
> >
On 10 December 2017 11:05:23 GMT+00:00, Niklas Keller wrote:
>>
>> This. There's nothing undefinable about "1 instanceof \stdClass",
>the
>> clear and obvious answer is: "No, it's not an instance of \stdClass,
>> it's an integer." The runtime result of false makes sense, the
>> compile time erro
On 10.12.2017 at 12:05, Niklas Keller wrote:
>> This. There's nothing undefinable about "1 instanceof \stdClass", the
>> clear and obvious answer is: "No, it's not an instance of \stdClass,
>> it's an integer." The runtime result of false makes sense, the
>> compile time error doesn't. Let's re
>
> This. There's nothing undefinable about "1 instanceof \stdClass", the
> clear and obvious answer is: "No, it's not an instance of \stdClass,
> it's an integer." The runtime result of false makes sense, the
> compile time error doesn't. Let's relax the compile time error (fold
> it into a con
20 matches
Mail list logo
