Scramble Files

Deeper setter analysis

When analyzing method calls, Scramble now infers much more useful type information thanks to deeper setter analysis.

Consider this example:

:::php
class Foo
{
    property int $foo;

    public function __construct()
    {
        $this->setFoo(42);
    }

    public function setFoo(int $foo): self
    {
        $this->foo = $foo;
        return $this;
    }
}

Previously, Scramble correctly inferred that new Foo() produces a Foo<42>.

However, if you move the setter call into a setup method, Scramble used to lose that information:

:::php
class Foo
{
    property int $foo;

    public function __construct()
    {
        $this->setup();
    }

    private function setup(): void
    {
        $this->setFoo(42);
    }

    public function setFoo(int $foo): self
    {
        $this->foo = $foo;
        return $this;
    }
}

In this case, Scramble would no longer know that $foo had been set to 42.

This release fixes that: the example above now works perfectly as expected. Deep setter analysis applies not only in __construct but in any class method.

This enhancement makes Scramble more accurate across a broader range of codebases, letting you focus on your business logic instead of adding extra annotations.

Performance improvements

Deeper setter analysis requires analyzing more code and doing more work. So initially, the draft version of this feature severely impacted Scramble's performance (slowing it down by 2x — sic!).

Fixing this performance regression not only resulted in a 10% speed-up over the original performance levels but also slightly reduced memory usage.

Long story short: the performance gain came from skipping work that wasn’t absolutely necessary. So, going back to the latest example: if setup or setFoo methods are never called in places Scramble actually cares about (like API controllers), they won’t be analyzed — which significantly boosts performance.

Also, if you have a statement like return count(some_complex_function()), some_complex_function() won’t be analyzed at all, since count is known to return an int regardless of the arguments you pass.

This required some internal changes to how arguments are handled, which might technically be breaking changes — but they shouldn’t affect you, since it’s all internal.

🚨 Potentially breaking changes

This release does not introduce any changes to the public API documented in the docs. However, if you rely on undocumented internals to extend type inference, please note:

• All call event classes' arguments property is now an instance of Dedoc\Scramble\Infer\Contracts\ArgumentTypeBag, instead of plain array<string, Type>. This affects Dedoc\Scramble\Infer\Extensions\Event\{AnyMethodCallEvent, FunctionCallEvent, MethodCallEvent, SideEffectCallEvent, StaticMethodCallEvent} classes.
• The early "side effects" concept has been replaced by industry-adopted self-out types (does anyone understand this sentence at all?). As a result, the following classes have been removed: Dedoc\Scramble\Support\Type\SideEffects\{SelfTemplateDefinition, ParentConstructCall}.

What's Changed

• Added 'present' validation rule support by @chrisvanlier2005 in https://github.com/dedoc/scramble/pull/915

Full Changelog: https://github.com/dedoc/scramble/compare/v0.12.26...v0.12.27