Move Serialization module back into a core/lib component

Seems like there's a couple of ways we could move towards this without breaking bc:

1. If we do the plugin idea from one of the original issues, we could add a /new/ core service using the plugins, serialization module would then be a bc-layer providing the old services. That's fine for a minor release.

2. If this ends up just moving the services to core.services.yml and no module, then that could happen and leave an empty module that doesn't do anything. There's potentially an issue with conflicts (say a competing module registering the same service names that requires serialization to not be installed?) but not sure how much of a real issue that is.

So I'm moving this back to 8.x on the basis that the situation can be improved there - if either #1 or #2 happened the only task for 9.x would be git rm.

Is this still targeting 8.0.x ?

Paramconverters, Event listeners etc.
Paramconverters, which are never expected to be used directly either as services or value objects, are not considered part of the API. You should not extend from these classes and provide your own implementation instead.

This really sounds similar to what encoders/normalizers are meant to be used for. On the other hand there are interfaces in there, we should certainly keep with a deprecation notice.

For now I just moved all the classes but when I talked with @damiankloip about it, we kinda agreed that many of the classes are probably extended.

Do we think we want to tackle that in 8.2.x?

For now I just moved all the classes but when I talked with @damiankloip about it, we kinda agreed that many of the classes are probably extended.

Indeed. So this probably needs to leave a BC layer… and that's not going to be pretty AFAICT.

Beauty is in the eye of the beholder ;)

hehe. It is indeed. I would say that this should now just be punted to D9...

@damiankloip
If someone would do it, I'd be happy with it, but yeah the effort around the BC would be quite a bit actually. Maybe someone comes up with a clever script though.

I'm not sure this is worth doing in-itself for 8.x. However with an ugly bc layer, it would mean forward-compatibility if we wanted to do it in 9.x (i.e. an 8.x module could rely on the new classes, and work on 9.x with no changes). That in turn makes it worth doing for 8.x again ;)

Well there's also #2575761: Discuss a better system for discovering and selecting normalizers that explains how the current normalizer selection system (i.e. Symfony's system) is a major PITA for something like Drupal. The Symfony serializer component works great if you write a normalizer for each object type, and can call it a day.

But Drupal doesn't use just objects… it uses object hierarchies (entities contain fields which contain field item lists which contain field items), and each level can have its own normalizer.

On top of that, modules can extend/decorate/override normalizers to suit their own needs.

With service priorities, this is an incredibly brittle PITA.

Therefore, I'd vote to won't-fix this because #2575761: Discuss a better system for discovering and selecting normalizers already implies we'll need to replace the Serializer component in D9.

Yes, essentially my vote would still be to not do this/won't fix it.

The forward compatibility would be a very good argument, but as Wim suggests above, we will very likely want to re-architect how our serialization API looks for D9. It needs to be completely re-thought out based on our needs and good experience from the evolution of D8. This could mean making a new component instead and just removing the serialization module. I think we were too hasty to just go with the Serialization component, and also it was added before a lot of other entity API stuff existed - meaning it has just got more tangled over the last few years. So based on that, I think we live with what we have currently.

Marking this as won't fix for now. If anyone disagrees, please re-open and we can talk about it!

#17: great additional information about the context & evolution of the Serialization module :)