Adding columns defined in actAs-templates to the docblock of the generated model class

[thirsch]

The generated docblock does not contain the columns defined in the referenced behaviours (actAs). This patch adds those columns to the docblock.

@alquerci, @connorhu, @thePanz, wdyt about this addition? I'd create a test for it, if you are interested in the change at all.

[alquerci]

wdyt about this addition?

It is an interesting idea, to provide better developer experience.

However, I am not sure about the time to invest on this new feature.

In any case, I like to read tests as they show examples.
Even a failing test, will be enough to sense it.

[connorhu]

I am a progressive person. If the change will move your work forward or you see it as helping others in their work then go for it.

[thirsch]

I've updated the pr:

• included a test case
• don't throw an exception anymore, if the class defined as actAs does not exist
• don't introduce a BC change as all new parameters are additional optional arguments to the public methods

wdyt?

[alquerci]

@thirsch it is better than before.

Let's add this new behaviour and make it with a good job.
It's a good opportunity to sense the effort to make changes there without fear.

How do you feel when making changes in this class?

[thirsch]

How do you feel when making changes in this class?

Well, I still think we should keep changes in the sense of new features to a bare minimum or try to avoid it at all. For this particular topic, it was more like a bug to us, as this saves a lot of manual added typehints in the codebase. Sure, it is no bug as such, as it was absolutely not a topic back in the days when this code base was written.

[alquerci]

this saves a lot of manual added typehints in the codebase

What does forces you to add these type hints ?

I have 2 hypotheses of usage and constraints, but I wish to know yours.

[thirsch]

this saves a lot of manual added typehints in the codebase

What does forces you to add these type hints ?

I have 2 hypotheses of usage and constraints, but I wish to know yours.

It's primarly a question of inconsistency of having the "direct" fields documented whilst the "inherited" once are not. Points are: ide support (code completion, type checks), tools like psalm/phpstan and even good old pull request review, where the fields are there and can be found by checking what has been created/changed.

[thirsch]

I've changed the loosely testing "contains"-checks to a snapshot testing to avoid sideeffects being generated. IMHO this even allows a clearer view on what exactly is this change doing.

[thePanz]

Some minor comments, LGTM otherwise!
Thank you for your work and commitment! Kudos!

[thirsch]

Thanks for merging it :)