#48in24: grade-school 2024-10-15

[mk-mxp]

• [x] Run bin/configlet sync -u -e grade-school --yes --docs --filepaths --metadata --tests include (updates the Markdown files and maybe tests.toml)
  • docs: instructions unsynced: grade-school
  • metadata: unsynced: grade-school
• [x] Drop strict types comments from test file and example code (these are useless)
• [x] Add and sync test meta data to tests (uuid / @testdox in DocBlocks)
• [x] Decide on adding / adjusting / ordering test cases to match current problem specs
  • grade-school: missing 16 test cases
  • Very likely: tests.toml is missing, but tests are there

Do not redesign the student's interface or add test cases that would invalidate existing community solutions. These are extra tasks, which should be discussed in advance.

[tomasnorre]

I had a short look at the sync of the Grade School exercise.

The functions in the current design, doesn't match problem specifications. https://github.com/exercism/problem-specifications/blob/main/exercises/grade-school/canonical-data.json#L11

We have no functions call roster in the blueprint class. Unless I misunderstand something, I think it will get hard to get this in sync without redesigning the exercise.

[mk-mxp]

Well, that's how it is. Let's look at the statistics and options:

552x started, 388x solved -> quite many for PHP exercises. It is of medium difficulty, the description has a "bonus section" about data encapsulaton. Last API change was 3 years ago, adding testing for uniqueness of names using add(), but PHP track didn't do that. PHP track exercise is > 7 years old with only strict_types added. The incompatibilities are: void not bool return type on add() (and so no value returned), method studentsByGradeAlphabetical() instead of roster(), current description has no "bonus section".

The change in problem-specifications breaking the API was made to cover the ever-existing requirement "student names must be unique across the school". That is an important requirement to enforce and complaints were already there about that.

I thought about adding a "compatibility layer" calling studentsByGradeAlphabetical() instead of roster() when it exists and skipping add() return value tests for old implementations. But a) this makes tests unreadable for students and b) is a burden to maintain in the long run. So I don't think it is worth the effort.

Looking at all this, I'd prefer to:

Update the exercise to the current problem-specifications API. This will break all current solutions. We may optionally add a re-worded "bonus section" about data encapsulation in instructions.append.md.

[mk-mxp]

@tomasnorre @fejan-malek @sarad1p1ty Someone taking care of this? I'll work on it Monday, if no-one chimes in.

[tomasnorre]

I haven't had the time. But can see if I get to it. If no one is assigned when I find the time, I'll assign myself when starting.

[mk-mxp]

As the exercise is featured today in #48in24, I have continued it in #817. Thanks for starting this!