exercism / exercism/problem-specifications

Meta: adding new keys to the schema

Ouverte
#1,496 44 commentaires 2 réactions 0 personnes assignées Voir sur GitHub
cross-track consistency discussion
Langage dominant
Ruby
Étoiles
358
Forks
563
Merge moyen
18 h 41 min
PR mergées (30 j)
2

Description

I've changed the title to be a meta discussion, so that we don't have the same discussion in multiple issues:

- [optional flags](https://github.com/exercism/problem-specifications/issues/1492) #1492
- [immutability flags](https://github.com/exercism/problem-specifications/issues/1493#issuecomment-478563670) #1493
- [other types of tests](https://github.com/exercism/problem-specifications/issues/1225#issue-314244907) #1225
- multiline "type"
- [identity field](https://github.com/exercism/problem-specifications/issues/1473) #1473 (to avoid compromising [descriptions]( https://github.com/exercism/problem-specifications/pull/1525) #1525 to fit this purpose)

It seems there really is a lot of ask for new fields and there also seems to be a notion that we don't want to break the current generators.

Personally, I am currently parsing the comments for special behaviour and this means that my generators will all break when someone decides the comments should be a special format. I can derive no special meaning from the english in these comments. I don't think this is the right place to hold special cases, but it is for things not covered in the current scheme.

I know that you (@pgaspar @ErikSchierboom @coriolinus @sshine @SaschaMann and @NobbZ) are all involved with writing and maintaining the generators, or at least the discussions on GitHub:

- I think it would be wise to discuss first if we'll add new keys, if at all, because so far each issue has already raised the "yeah okay but we don't _really_ need it and it costs me work"-type comment
- ...and then which ones are candidates, so we can merge it at once and the burden on maintainers is much lower, as the raised point just mentioned _is valid_.
-----------

Original issue about multiline.

There is canonical data such as [`food-chain`](https://github.com/exercism/problem-specifications/blob/master/exercises/food-chain/canonical-data.json#L4) and [`twelve-days`](https://github.com/exercism/problem-specifications/pull/954/files#diff-dcda8ef37a4982f40c53174662e64ebdR5) that correctly comment:

> JSON doesn't allow for multi-line strings, so all verses are presented
> here as arrays of strings. It's up to the test generator to join the
> lines together with line breaks.

Okay, that's great! But in this case I think it would be _great_ if we'd add a meta property (and keep a list of those, as there are more like these (such as a property preferably being a constant or at least immutable) so that we can automate generation of these exercises.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.