exercism / exercism/problem-specifications

Meta: adding new keys to the schema

Abierto
#1,496 44 comentarios 2 reacciones 0 asignados Ver en GitHub
cross-track consistency discussion
Lenguaje dominante
Ruby
Estrellas
358
Forks
563
Merge medio
18 h 41 min
PR fusionados (30 d)
2

Descripción

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.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.