[WIP] [Serializer] Alias support #15200
Conversation
| * @return string | ||
| */ | ||
| public function normalize($propertyName); | ||
| public function normalize($class, $propertyName); |
There was a problem hiding this comment.
An easy way to limit the BC break is to inverse parameters (same for denormalize).
There was a problem hiding this comment.
According to the BC promise, you'd need to make $class the second argument and make it optional. That's not ideal, but I don't think there's another way
There was a problem hiding this comment.
@weaverryan even if you make it optional, it is still a BC break: people implementing the interface will have to change their code, otherwise they will get PHP errors about signature mismatches.
There was a problem hiding this comment.
I'm reading this from (my recent new best friend) out BC promise: http://symfony.com/doc/current/contributing/code/bc.html#changing-interfaces for non-API interfaces, we are allowed to add optional arguments to methods. Am I reading that wrong? Or perhaps that's not correct?
There was a problem hiding this comment.
Well, it says Should be avoided, because it is still a BC break. The Regular column is a column saying "We don't actually provide BC here, but only partial BC".
And actually, I don't think any code added since 2.3 has actually been tagged as @api. Many things are extension points for our users where we care about BC as if they were flagged as @api even though it was not done.
Given that we became better at writing BC layers than a few years back, we may decide to drop the distinction between Regular and API btw. The default behavior of a class should be full BC. The meaningful distinction would be Regular vs Internal (where internal classes not meant to be used by users are less strict on BC)
| * | ||
| * @author Kévin Dunglas <dunglas@gmail.com> | ||
| */ | ||
| class Alias |
There was a problem hiding this comment.
I like the SerializedName from JMS more than alias, which seems to tell me less about what it does. Any reason for using alias specifically?
There was a problem hiding this comment.
@weaverryan agree with you, but Alias is still understandable
|
@dunglas would I have to use the AliasNameConverter to use aliases? Could I alias some properties, but allow other un-aliases properties to use a a different name converter? |
|
@dunglas This one looks unfinished. Will you have time to finish it in the coming weeks? |
|
It's the last one on my todo list... Not sure it's even possible to finish it without BC break. |
|
What about skipping the name converter entirely if there's an alias specified? I think that makes more sense conceptually (i.e. there's no need for automatic name generation because the desired name is already specified)... |
|
Hopefully that also obviates the need to change the name converter's method signature... |
| @@ -70,25 +75,29 @@ public function loadClassMetadata(ClassMetadataInterface $classMetadata) | |||
| foreach ($reflectionClass->getMethods() as $method) { | |||
| if ($method->getDeclaringClass()->name === $className) { | |||
| foreach ($this->reader->getMethodAnnotations($method) as $groups) { | |||
| if (!preg_match('/^(get|is|has|set)(.+)$/i', $method->name, $matches)) { | |||
There was a problem hiding this comment.
Sometimes the getter name is simply the name of the property without any prefix. I think it would be good to support it too.
|
@dunglas any news about this one? |
|
#18016 looks more promising (but is limited to |
Follows up #15171. It's the POC I was speaking about @estahn
Progression:
The main issue about this PR is that it introduces a huge BC break in the Name Converter. To make it working it's needed to inject the current object or at least its class in the name converter and it's currently not possible.
What do you think about that @symfony/deciders?
@estahn you're welcome to contribute or rework this PR!