Object access in `Runtime::lookupValue`

[eliashaeussler]

As you know, we use this library as base for our TYPO3 handlebars extension. While this works quite well (thanks again for all your efforts! ❤️), we repeatedly run into a limitation with the current implementation.

It's quite common in TYPO3 to pass objects to templates and later access properties and/or methods. Imagine something like this:

final readonly class Foo
{
    public function __construct(
        public string $bar,
        private string $boo = '',
    ) {}

    public function getBoo(): string
    {
        return $this->boo;
    }
}

$foo = new Foo('bar');

$template = <<<HBS
Bar: {{foo.bar}}
Boo: {{foo.boo}}
HBS;

$template = \DevTheorem\Handlebars\Handlebars::compile($template);
$result = $template(['foo' => $foo]);

In this particular example, we cannot access neither the bar property nor the boo property (through getBoo method). I understand that this contradicts the original Handlebars.js implementation and I don't ask for an explicit support for this specific use-case. But do you see any possibilities in providing a dedicated hook (or similar) in order for us to provide a specific implementation for lookups (as addition to the existing Runtime::lookupValue method)?

[theodorejb]

I'm glad the library is working well!

Your example of {{foo.boo}} accessing a private property is a bit confusing to me. Are you expecting this to compile to a $foo->getBoo() call? How would PHP Handlebars know to do that vs. accessing a property like for {{foo.bar}}?

Currently for a template like {{foo.bar}}, the compiler assumes that foo will be an array and generates:

LR::escapeExpression(LR::lambda($in['foo']['bar'] ?? null))

In order to support both arrays and objects passed to the same compiled template, the compiler would have to generate nested method calls like LR::prop(LR::prop($in, 'foo'), 'bar'), which would add some runtime overhead.

[theodorejb]

I took a stab at implementing basic support for context lookups on objects, and the performance overhead ended up being relatively small (~7.5% increase in runtime on my benchmark). You can try it out via the context-objects branch (composer require devtheorem/php-handlebars:"dev-context-objects"). Let me know what you think of this.

[eliashaeussler]

Thank you for your time in implementing a first approach.

Some more context regarding this issue: In TYPO3, we mainly use the symfony/property-access approach as described here. That means, when accessing a property path like foo.boo, the property accessor performs several checks on the foo object: (1) Try to read from public property $foo->boo, (2) Try to read from getter $foo->getBoo() and so on. Since this approach has been well established in TYPO3 projects, I'd like to offer it in our Handlebars extension as well. Hence the "feature" request 😉

Your current implementation covers the first approach, accessing a public property, but it leaves out other approaches. That's totally understandable, and that's why I preferred some "hook-method" (something like you already head as partialResolver, just for objects, e.g. propertyResolver or similar). This would keep your implementation clean from more customized solutions and would allow us to implement our approach. WDYT?