Error parsing Job class with uninitialized typed properties

[hackel]

• Telescope Version: 4.4.0
• Laravel Version: 8.19.0
• PHP Version: 7.4.13

Description:

When a Job class contains typed properties that are not initialized with a default value nor set in the constructor, an error is thrown: "Typed property x must not be accessed before initialization".

I believe to solve this in a backward compatible way, it would require something like this in Laravel\Telescope\ExtractProperties::from:

if (version_compare(phpversion(), '7.4', '>=') && !$property->isInitialized($target)) {
   return [$property->getName() => null];
} else {
	...

Not sure if you would rather return some type of UninitializedProperty object instead so that this could actually be distinguished from null in the UI.

Steps To Reproduce:

    public function test_extract_properties_from_class_with_uninitialized_typed_properties()
    {
        $properties = \Laravel\Telescope\ExtractProperties::from(
            new class {
                private string $uninitialized;
            },
        );

        $this->assertEquals(['uninitialized' => null], $properties);
    }

[driesvints]

This isn't a Telescope issue. Provide a default value for the property if you aren't setting it when initialising it in your app.

https://stackoverflow.com/questions/59265625/why-i-am-suddenly-getting-a-typed-property-must-not-be-accessed-before-initiali

[hackel]

@driesvints It is absolutely a Telescope issue. Telescope is supposed to be passive and not dictate how my code must be written. Telescope is what was responsible for accessing a variable before it has been initialized, not me.

More info on at least one situation where this comes up with Laravel: in Job classes, only the handle method receives injected dependencies, not the constructor, so they must be assigned later. If you try to do it in the constructor by e.g. using resolve(Dependency::class), then a representation of that dependency will get stored when the job is queued, which really breaks things. Making the types of these dependencies nullable when they shouldn't be is bad design, particularly when the fix is so simple.

[driesvints]

@hackel it's not. Please read the stackoverflow link I added above.