class_serializers supports closures

[tw2066]

class_serializers supports closures

eg.

    'class_serializers' => [
        'callable' => static function (object $object) {
            if(\Hyperf\Stringable\Str::startsWith($object::class,'HyperfExample')){
                return json_decode(json_encode($object),true);
            }
            return $object;
        }
    ],

[stayallive]

This doesn't do what you think it does, have you tested your change? Your change currently will run the serializer for any type and is a big breaking change and also not how class_serializers is documented to work.

The serializer already can be a closure just like we do in our test cases:

sentry-php/tests/Serializer/SerializerTest.php

Lines 111 to 119 in d12ed37

	$serializer = $this->createSerializer(new Options([
	'class_serializers' => [
	$objectClass => static function ($object): array {
	return [
	'purpose' => $object->getPurpose(),
	];
	},
	],
	]));

The key in class_serializers must match the class your callback is serializing, so "function" in your example probably won't work but needs to be some (base) class available in your application.

[tw2066]

Consider making a special judgment on type

[cleptric]

This needs tests and I'm currently not convenient why this change is needed in the first place.

[tw2066]

Some classes are not inherited，unified processing can be achieved through namespaces or other judgments

[stayallive]

When using our ClientBuilder directly you can set your own serializer (that extends the SDK one potentially) in which you can do whatever you want:

sentry-php/src/ClientBuilder.php

Lines 78 to 83 in d12ed37

	public function setRepresentationSerializer(RepresentationSerializerInterface $representationSerializer): self
	{
	$this->representationSerializer = $representationSerializer;
	return $this;
	}

This current approach doesn't make sense to me, class_serializers with a magic key where the key is not a class name is going to cause much confusion. So either a custom serializer is the way to go here or creating a whole new option (object_serializer maybe) to support a catch-all serializer for objects could make sense but then we might want to create a more generic option to serialize more types.

Anyway, using the client builder seems like the best bet here for your specific needs?

[cleptric]

I agree with @stayallive on this.