Works great :) I don't think there are currently any other refactorings that can benefit from this now -- but I can imagine changing the f.e. the generate accessors to operate based on a list -- would allow to generate accessors for all properties f.e.

Otherwise, I merged the other PR, and just have to wait for a green build here :)

Originally posted by @dantleech in #773 (comment)

As discuss there I already had started to work on it.
But I realized that I might be taking the problem from the wrong side.

What I did is change the handler to make the offset optional and add another optional parameter for the properties names.
If names are provided I use WorseReflection to find the property.
Then I use the position and the visibility to retrieve the offset of the property, because the start of the position if before the visibility but the offset start after it. So I add the visibility length to the start position to get the offset.

Two things bugs me here:

• It feels kind of hacky to "build" the offset from scratch
• The handler should only be a bridge between the RPC extension and the actual transformers

So I came up with another solution.
I still handled both offsets and name in the handler.
But I changed the GenerateAccessor API to provide two functions:

• generateFromOffset
• generateFromPropertyName

The generateFromPropertyName has the responsibility to use WorseReflection to find the property and create the SymbolContext used by the transformer based on the position.
It feels less hacky since a Symbol can be build form a position.
But it's a bit more changes and I sill don't have a good view of the global project.

So I was wondering what is your thoughts about that and how you would prefer to implement it.

P.S.: If the second option is choose, it might also be a good idea to be able to generate a SymbolContext from a ReflectionMember.
Something like SymbolContext::fromReflection($member) ?
Or would it be against the original design ?