[RFC] [laminas/laminas-code] Add type hinting option in PropertyGenerator

I’ve been using the code generator package for over 10 years and I’m surprised to see there’s still no option to add type hinting on PropertyGenerator.

In the past I just rely on DocBlock to do type hinting for generated property. But it’s almost 2022 now and PHP 8.1 ls released, I my other packages have been using type hinting everywhere, my generated code can handle no more without proper type hinting.

I’m not sure the lack of such feature is because BC reasons or simply because nobody cares to do it. I presume it the later and will post a PR hopefully somebody in charge can notice it quickly…

Hello and welcome to our forums! :smiley:

You have been very active in the meantime and created a pull request: :+1:t3:

It can be a BC break, if the typ hint is not optional because the created code is different and if someone created tests for the produced code, these can also fail. And the created code will not work in older PHP versions.

You are making a valid point.

However the way I see it is bearable BC break. According to PHP’s official web site: 'Type declarations can be added to function arguments, return values, and, as of PHP 7.4.0, class properties. ’

From what I can tell, the package itself requires PHP >= 7.4

And the unit test is against PHP 7.4 / 8.0 / 8.1 only, looks like we are not dealing PHP < 7.4 anymore. So am I right to say this BC break isn’t so BC breakable?

The last thing I can do is to add another switch into PropertyGenerator::fromReflection() to turn off the type hinting generation by default, however I feel it adds unnecessary complexity. We don’t have to worry about PropertyGenerator::__construct() or PropertyGenerator::fromArray() because the $type option is nullable.

But this does not mean that the generated code will not be used in another environment.

Also think of existing systems: the output is now different.

Hey Frank,

if people generate code with laminas/laminas-code, then run it on PHP <7.4, then it’s totally their problem.

For example, laminas/laminas-code can generate ENUMs, readonly properties, etc: that’s already out of scope from a compatibility PoV.

It’s a non-issue, in this case: the tool has no restraints on the type of code it generates.

What is important is that the tool can mirror pre-existing code with its generator, but otherwise don’t worry about it :slight_smile:

Looks like to me adding the switch is the answer now :stuck_out_tongue:

@froschdesign @ocramius Improvement has been added for BC purpose.