[5z7k9]

> xs = ['10', '10', '10']

> xs.map(parseInt)

[10, NaN, 2]

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
#programowanie #javascript #heheszki #humorinformatykow

[regis3]

C++:

vector vec = {"10", "10", "10"};

vector result;

transform(vec.cbegin(), vec.cend(), back_inserter(result), [](auto&& el){ return stoi(el); });

@KrzaQ2: Niezła manipulacja, tylko że zamiast anonimowej powinieneś dać dam stoi. Wtedy ktoś może napisać, że niezła #!$%@? bo nie da się dać tam samego stoi.

[KrzaQ2]

@regis3: No niestety, bo jest jeszcze przeładowanie dla wstringów.

vector vec = {"10", "10", "10"};

vector result;

transform(vec.cbegin(), vec.cend(), back_inserter(result), &atoi);

lepiej?

[regis3]

@KrzaQ2: Wiesz chociaż co nadal udowadniasz? Ja chcę tam stoi tak jak ty wpieprzyłeś tam parseInt.

[macrusher]

błąd programisty błędem programisty. Taki kod jest mylący, a język na to bezproblemowo pozwala. I to nie jest ułomność?

@KrzaQ2: Kwestia definicji słowa "ułomność". JS ma bardzo daleko do ideału, ale jeżeli ten przykład jest dowodem na ułomność to praktycznie każdy język jest ułomny.
Rozumiem że C++ jest ułomny bo mnie nie powstrzyma przed #define TRUE FALSE albo innym idiotyzmem?

[KrzaQ2]

@regis3: ale stoi samo w sobie się nie skompiluje, chroniąc programistę przed ewentualnym błędem. To nie jest ułomność języka. Ułomnością np. jest przełykanie błędnego i mylącego kodu bez nawet zająknięcia.

A udowadniam, ƶe we wszystkich znanych mi językach, czytając kod mapujący listę stringów na inty za pomocą funkcji o nazwach generalnie powiązanych z toint/parseint/read otrzymam listę intów (lub błąd kompilatora/interpretera), dzięki czemu moƶna to nazwać pewnego rodzaju regułą.

[KrzaQ2]

@macrusher: oczywiście, ƶe to jest wada. http://programmer.97things.oreilly.com/wiki/index.php/Make_Interfaces_Easy_to_Use_Correctly_and_Hard_to_Use_Incorrectly

#define true false jest idiotyzmem, ale imho gorsze są rzeczy które cięƶko wychwycić w code review, np. przekazanie do algorytmu iteratorów z róƶnych kontenerów o tym samym typie. Kompilator tego nie wychwyci. Wszystko wygląda ok, ale jest UB.

[regis3]

@KrzaQ2: Tylko w takim razie, jak w dynamicznie typowanym języku programista jest powstrzymywany przed błędnym użyciem funkcji bo trochę nie kumam. Wiesz jak działa map w js, wiesz (już) jakie parametry wstrzykuje map, więc gdzie tu jest niejasność.

w c# mamy Convert.ToInt32("12", 8);

w js mamy parseInt('12',8);

Serio nie kumam o co chodzi z tym przykładem.

[KrzaQ2]

@regis3: jeśli to niemoƶliwe w js to zdecydowanie nazwałbym taki błąd projektu biblioteki standardowej niedociągnięciem/ułomnością języka. Ruby i Python teƶ są dynamicznie typowane i jakimś cudem są w stanie rzucić wyjątek gdy dostaną inną od spodziewanej ilość parametrów funkcji.

Kod, który dla osoby postronnej jest czytelny, ale robi coś zupełnie innego niƶ moƶna wyczytać nie moƶe być nazwany dobrym, a jeśli język/framework/api/biblioteka w tym nie przeszkadza to jest to błąd.

Ƶeby

[regis3]

Ruby i Python teƶ są dynamicznie typowane i jakimś cudem są w stanie rzucić wyjątek gdy dostaną inną od spodziewanej ilość parametrów funkcji.

@KrzaQ2: Tutaj się zgadzam. Co do reszty to trochę naciągane to było.

[KrzaQ2]

@regis3: Nie do końca. Wszędzie masz lista.mapuj(naint) i wszędzie masz ten sam rezultat. No, prawie.

[A.....k]

@regis3: @KrzaQ2: Tak ponad tym co piszecie zasadniczo jeśli funkcja przyjmuje dwa argumenty a dajemy jej trzy albo dowolną ilość argumentów kompilator/parser powinien i tym powiadomić.

[regis3]

@Analityk: @KrzaQ2: A co jeśli parseInt przyjmowałoby 3 parametry? :>

Poza tym parametry mogą być domyślne więc to nie rozwiązuje problemu dynamicznego typowania.

[KrzaQ2]

@regis3: błąd designu biblioteki.

Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly

~ Scott Meyers

[regis3]

@KrzaQ2: Czyli jeśli metoda pasuje do map parametrami ale jej użycie jest bez sensu to też błąd designu?

[KrzaQ2]

@regis3: Ogółem tak, szczególnie jeśli zauwaƶenie faktu, ƶe jest bez sensu wymaga co najmniej niezłej znajomości języka/jego biblioteki standardowej.

[A.....k]

@regis3:

['1', '2', '3'].map(returnInt); // [1, 2, 3]

// Actual result is an array of numbers (as expected)

"as expected" chyba nie pasuje do reszty ideologii biblioteki. Druga sprawa, to założyłbym, że parseInt domyślnie pobierze jeden element z tablicy a drugi pozostanie domyślny, skoro nie przekazuje do funkcji czegoś typu

[ {'1',0}, {'2',0}, {'3',0} ].map(parseInt);

[regis3]

@Analityk: no tak ale to nie jest problem parse int tylko tego jak działa mapa.

arr.map((element, index, table) => {})

więc parseInt nic nie pobiera. Iterator wywołuje na nim:

parseInt(element, index, table);

3 parametr jest ignorowany, ale 2 pierwsze są jak najbardziej ok. Pierwszy to w naszym przypadku string ('10') a drugi baza systemu liczbowego.

That's it.

edit:

Jedyne czego może nie wiedzieć/ nie spodziewać się programista to fakt że parseInt