Dlatego StrictYaml tego nie robi.

Problematyczna Norwegia

Okazuje się, że jeśli używasz pyyaml do pliku konfiguracyjnego możesz się kiedyś zdziwić, że nie wszystko działa jak powinno. I spędzić długie godziny (dni?) na szukaniu przyczyny problemu, która będzie kryła się w najmniej oczekiwanym miejscu.

Załóżmy, że stworzyłeś stronę internetową. Klient zażyczył sobie po jakimś czasie aby ją umiędzynarodowić – zrobić kilka wersji językowych. Dodajesz więc plik konfiguracyjny i zapisujesz w nim poszczególne symbole narodowe:

countries:
- GB
- IE
- FR
- DE

I wtedy klient wpada na pomysł, że potrzebuje jeszcze wersję norweską. Dodajesz odpowiedni kod NO a potem wszystko się sypie. „Co się stało się”?

Czasami „nie” wcale nie znaczy „nie”

Ano otrzymałeś {'countries': ['GB', 'IE', 'FR', 'DE', False]}. Kiedy przekażesz takiego false’a do kodu, który oczekuje stringa (np. „NO”) to kłopoty gotowe. Najprościej pozbyć się tego problemu z pomocą cudzysłowów:

countries:
- GB
- IE
- FR
- DE
- ‘NO’

Zamierzona katastrofa

Najgorsze jest to, że nie możesz mieć pretensji do nikogo innego niż samego siebie. Takie działanie jest zgodne ze specyfikacją YAML 2.0. Prawdziwa poprawka wymaga po prostu wyraźnego zignorowania specyfikacji - i tak postępuje większość parserów YAML. StrictYAML omija ten problem, ignorując kluczowe części specyfikacji i próbując przez to stworzyć coś co można by nazwać parserem „zero niespodzianek”. Po prostu domyślnie wszystko jest ciągiem znaków: {'countries': ['GB', 'IE', 'FR', 'DE', 'NO']}.

Numery wersji

Norwegia to tylko jedna ciekawostka. Prawdziwe kłopoty zaczynają się z numerami wersji. Załóżmy, że zamiast:

python: 3.5.3
postgres: 9.3.0

napiszesz:

python: 3.5.3
postgres: 9.3

Oj, narobiłeś sobie kłopotów. Otrzymasz wtedy bowiem: [{"python": "3.5.3", "postgres": 9.3}]. Tak, w przypadku postgres nie dostajemy stringa lecz typ float. I znowu trzeba sobie radzić z domyślnym typowaniem z użyciem cudzysłowów (apostrofów).

A znasz Christophera Nulla? Pan Null nieustannie sprawia kłopoty swoim nazwiskiem twórcom systemów informatycznych. Prawidłowe parsowanie takiego nazwiska bez zadbania o typy nie jest możliwe.

Typowanie i jego rola

To jak sobie radzi dany język z typowaniem jest popularnym tematem wśród deweloperów. Dobrze zaprojektowany system typów jest uważany (i słusznie) za straszliwe jarzmo dla dewelopera, które jednak może wyłapać błędy jeszcze na wczesnym etapie rozwoju oprogramowania. Tymczasem źle zaprojektowane systemy typów stanowią żyzny grunt dla skrajnych przypadków błędów, wychodzących na jaw dopiero w runtime. Po prostu rygorystyczne systemy typów wymagają od nas dużo więcej z góry. Także języki znaczników, takie jak YAML, mają problemy z typami - jak pokazano powyżej.

Sprawdź oferty pracy na TeamQuest

Dwa rodzaje typowania

Typowanie statyczne to nadawanie typów zmiennym w czasie kompilacji programu. Zaletą takiego rozwiązania jest możliwość większej optymalizacji kodu oraz wykrycia większej liczby błędów w czasie kompilacji. Wadą jest natomiast konieczność pisania dużej ilości informacji o typach. Częściowo problem ten jest rozwiązywany przez inferencję typów i polimorfizm. Większość współcześnie używanych języków oprogramowania ma właśnie typowanie statyczne.

Z kolei typowanie dynamiczne polega na przypisywaniu typów do wartości przechowywanych w zmiennych dopiero w trakcie działania programu. Konkretne zmienne nie posiadają więc tutaj typów przypisanych przed uruchomieniem programu. Oznacza to, że typ zmiennej wynika z wartości jaką dana zmienna przechowuje. A więc dana zmienna może przyjmować różne typy co jest nie do pomyślenia przy trypowaniu statycznym.

Poczytaj też o typowaniu w TypeScript.