Coordination: Prepare for students code using PHP 8.4

[mk-mxp]

Similar to what we did for PHP8.3 in #155 - For exercism/php#884 we need to have the representer ready to accept PHP 8.4 code from students. The representer itself may run on a different PHP version.

@homersimpsons Can you outline the required work to do here? An actionable list of tasks would be perfect, but any hints are welcome.

[homersimpsons]

@homersimpsons Can you outline the required work to do here? An actionable list of tasks would be perfect, but any hints are welcome.

To me there is nothing to do:

• https://github.com/nikic/PHP-Parser already supports PHP 8.4
• https://www.php.net/releases/8.4/en.php there does not seem to be anything important to normalize, things that may be great to normalize are:
  • Asymetric visibility to public (maybe)
  • Removal of [\Deprecated] attribute
  • Normalization of new MyClass()->method() to always use parentheses (so the representation is the same as before)

I will upgrade the base image of the prepresenter to php 8.4 as I did in e0def59.

[mk-mxp]

I think the last normalization, "new MyClass()->method() to always use parentheses" is required. This was one of the PHP things I did wrong for years, and never learned it :) But it does not make any difference, and so is no "approach" on its own.

We should remove [\Deprecated], it makes no sense here.

I would see "using asymetric visibility" as a different approach to solve the encapsulation problem. So I'm against normalizing this. Normalizing it would also mean, students never see asymetric visibility in solutions. I'm sure we will have a concept around visibility one day and that should cover asymetric visibility also.

PS: Just for documentation - It's https://www.php.net/releases/8.4/en.php

[homersimpsons]

I would see "using asymetric visibility" as a different approach to solve the encapsulation problem. So I'm against normalizing this.

In practice, I do not think that we have any exercise about this. Hence, it is probably better to normalize this so the comments on representation could be more general.

[mk-mxp]

@homersimpsons I don't understand the "so the comments on representation could be more general" issue. The representer does not comment on anything as far as I know. It provides "the normalized solution" to mentors, right? And it is used to identify duplicates of published solutions in the community solutions. Do you mean "mentors comments" could be more general?

I'm sure it will be long until students start submitting code with asymmetric visibility - and most probably they will start doing so when we ask for it in a concept exercise.

Anyways, I think it should be visible to mentors if such an advanced concept is applied to exercise solutions. So mentors can react to the use of it. If it's hidden, no questions around it can be asked or misuse pointed out.

[homersimpsons]

It provides "the normalized solution" to mentors, right?

Yes and no, when a mentor mentors a specific solution he does not see the normalized one. If you have access and go to https://exercism.org/mentoring/automation you can see the normalized solution on which you can comment, and when previewing and submitting the comment it is possible to see up to 3 non-normalized solutions that led to this normalization.

(If you do not have the required mentoring to have access you can create a pull request to add yourself to https://github.com/exercism/website-copy/blob/main/automators.json)

And it is used to identify duplicates of published solutions in the community solutions.

Yes, it is used to batch different solutions together, as well as to provide automatic comments for new solutions that have the same representation than an automated one. Currently it gives a feedback 41.8% of the time according to https://exercism.org/tracks/php/build.

Do you mean "mentors comments" could be more general?

I mean that a more diverse set of solutions will lead to the same representation, hence a comment will apply to more solutions.

About normalization:

• https://exercism.org/docs/building/tooling/representers/normalization gives some guidelines on what to normalize.
• From my understanding the goal is to "normalize what is irrelevant" so we can comment on what is relevant.

Note that, while unimplemented, it is possible to apply different normalization based on the exercise name. Doing so would allow us to have avoid normalizing things that are relevant for the exercise.

Ultimately the goal would be to implement an Analyzer which I started in https://github.com/homersimpsons/php-analyzer but never put that much time in it (yet).