> Would it make sense to not only add this for ReflectionAttribute, but
also Function and/or others?
There may be case where this makes sense but not necessarily in the use
case that i explain, and don't want to add more to this proposal, it's also
missing in ReflectionParameter, ReflectionProperty and certainly many
others if we go on this path then there is a lot of changes to apply and
will induce more friction for this proposal, i prefer to add small parts so
we don't deviate from the original use case.
> Do you have an example of how you expect this to be used? I'm having a
hard time understanding how I'd leverage this. (I maintain an attribute
enhancement library, Crell/AttributeUtils, so I've hit a lot of edge cases
in attribute design.)
Sure, let's say we have the following class
#[CustomAttribute(foo: 'foo')
#[CustomAttribute(foo: 'foo')
class Entity {}
And that later i have something that read those attributes, but i want to
throw an Exception when multiple attribute defined the same value for the
foo property (as it should be unique in my use case), i would not be able
to do that in the constructor since i don't have the context of others
attributes in this case, so i want to throw a custom exception explaining
it's caused by the attribute "CustomAttribute" in the file "Entity.php" at
line 4, as there is the same value in the file "Entity.php" at line 3
If I throw an exception without this message the error will pinpoint to
where I threw the exception and it may be confusing for the end user, by
having this he will know where to look and what to modify to make its code
correct.
> I would propose negating and renaming isUserDefined() to isInternal()
Both methods exists depending the context (there is a isUserDefined() in
the ReflectionClass class), but i'm fine with negating this if it's more
consistent
> As hinted in the PR, I believe the implementation is wrong,
I think the implementation is correct, i answered in the PR, i will add
more tests case that explain what is wanted here
> I'm also wondering whether it may be more useful to expose the attribute
class as getClass()
Do we not already have this with the getName() method ? or it can be wrong
if it's an alias by example ?
Joël
