Declare typed properties for internal classes without backing storage

[nielsdos]

Description

arginfo.h files contain calls to zend_declare_typed_property to create the property info and the backing storage.
The backing storage is not always necessary though, for example in ext/dom (and I think ext/date too, maybe others too), there are custom read_property and write_property handlers that write to an underlying struct instead of in the backing storage. The backing storage is therefore always of value UNDEF.

It would be great if there was an option, e.g. via the stub generator, to avoid the allocation of these backing storages. This has two advantages:

• Less memory usage per class instance
• When the extension creates a lot of objects, a lot of time can be spent in filling in those useless backing storages. This can be seen in a profile where a lot of ext/dom objects are created for example, which is not an uncommon scenario.

There are of course difficulties in implementing this:

• There is an offset field in the property info should point to the backing storage. If we don't have one, then we break assumptions of the users of this field.
• The engine uses default_properties_count (and similar for statics) to track the amount of used storage, but if there is no backing storage, then it will be 0 and the engine will incorrectly assume there are no properties.

I'm not sure if this is worth it given the complications above. However, I have a feeling something like this might be easier after https://wiki.php.net/rfc/property-hooks would be merged. That's because conceptually this feature request ties in nicely with the property hooks that don't have backing storage.

[iluuu1994]

@nielsdos Right, property hooks set offset to -1 the property is skipped for the object size calculation. That should work nicely for this case.

[nielsdos]

Thanks for clearing that up.
Nice that we can get it more or less for free then.
I'll keep this feature request open so I don't forget about it and we can track it. We'll still have to make changes to the aforementioned extensions to benefit from that optimization anyway.

[iluuu1994]

@nielsdos Tbh I wouldn't mind contributing this separately to make the property hooks PR simpler. At least if we still want those changes if property hooks were to be rejected.

[nielsdos]

Fine either way for me. I didn't look yet at your code so I have no idea how complex or difficult that part is, so can't really judge the benefit vs complexity trade-off :).

[SVGAnimate]

What append if we override $fullName ?

class User
{
    public string $fullName {
        get => $this->first . " " . $this->last;
    }
}

class EndUser extends User
{
    public string $fullName = "John McFly";
}

[iluuu1994]

@SVGAnimate This is not allowed in our RFC, if I remember correctly. This restriction may be relaxed in the future, but I don't consider it a significant use case. You can always work around it though.

class EndUser extends User
{
    private string $_fullName;
    public string $fullName {
        get => $this->_fullName;
        set => $this->_fullName = $value;
    }
}