Autor Wątek: Czy PHP jest dobre  (Przeczytany 29258 razy)

Offline Xirdus

  • Redaktor

# Grudzień 05, 2014, 00:52:35
A co przez to rozumiesz? Chcesz aby C++ był czymś w rodzaju C#, gdzie kompatybilność z C to już tylko jest w nazwie?
Nie. Chciałbym, żeby nie było implicit castów poza promocją podstawowych typów liczbowych, żeby inkrementacja zwracała void, żeby nie było operatora przecinka, żeby brak returna był błędem (obecnie jest warningiem - na jedno wychodzi, ale zawsze), żeby makra były sensowniejsze (obecne zasady powodują, że trzeba robić kilka makr, jedno wywołujące drugie, tylko po to żeby najpierw zrobiło podstawienie argumentów a dopiero potem sklejanie tokenów - co jest typowym przypadkiem), i kilka innych rzeczy które niesamowicie denerwują ale teraz mi wyleciały z głowy, a jedynym uzasadnieniem dlaczego C++ w ogóle ma takie bajery jest "bo tak zawsze było".

Tak totalnie przypadkiem wyszło, że według powyższej listy Rust jest dokładnie tym czym chciałbym żeby był C++... Tylko żeby jeszcze ogarnęli normalne dziedziczenie...

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline JasonVoorhees

  • Użytkownik
    • FotoGry

# Grudzień 05, 2014, 01:08:14
A czy nie można sobie włączyć w kompilatorze przynajmniej części feature'ów, których potrzebujesz? Np. w NetBeans (wiem, że to nie kompilator) widziałem warningi, gdy w PHP metoda miała więcej niż 20 linijek ;) Albo w GCC można włączyć, żeby C był strict (zgodność Ansi C), tylko, że przy niezgodności pluje co najwyżej warning, zamiast errora.

Offline Xirdus

  • Redaktor

# Grudzień 05, 2014, 01:20:13
Nie rozwiązuje to 4 z 5 w/w problemów.

Offline Xender

  • Użytkownik

# Grudzień 05, 2014, 23:25:12
Xtend z istniejącą biblioteką org.json.*.
var posts = data.optJSONArray("posts") ?: new JSONArray()
for (var i = 0; i < posts.length(); i++) {
    val filename = posts.getJSONObject(i).getString("tim") + posts.getJSONObject(i).getString("ext")
    // ...
}
Gdyby org.json.JSONArray lepiej wpisywało się w Java Collections byłoby czytelniej.
Nie znam Xtend, to ciężko mi się wypowiedzieć.

No te wszystkie Get*() okropne, ale to zrzucam na Javowość (brak przeciążania operatorów jako decyzja projektowa), a nie typowanie tego języka.

Jak tu zachowuje się var? Jak auto z C++11 (static inferred typing)?

W C++ z ładnie napisaną biblioteką mogłoby to wyglądać tak:
for (auto &post : json::json(data)["posts"]) {
    auto filename = post["tim"] + post["ext"];
    // ...
}
Pod spodem byłoby dużo konwersji i dynamicznego typowania ale taką bibliotekę powinno dać się napisać w C++11/14.
Ale ja nie pytałem, jakby mogło to wyglądać, mając bibliotekę-cud.
No ale niekonsekwencję już widzę: w moim kodzie str() jest nie dla ozdoby, tylko dlatego, że post['tim'] to akurat int.
Czyli biblioteka cud przy dodaniu dynamicznego-inta do dynamicznego-stringa zwracałaby jakiegoś stringa? Ugh.

Zresztą sam napisałeś, że pod spodem byłoby dużo dynamicznego typowania.
Czyli chcesz udowodnić, że język typowany statycznie nadaje się do takich rzeczy równie dobrze, co język typowany dynamicznie poprzez... użycie bibliotecznego type erasure w runtime?

Offline Dab

  • Redaktor
    • blog

# Grudzień 05, 2014, 23:28:34
Xender, ale akurat b. słaby przykład sobie wybrałeś na dogryzanie C++. :) Bo akurat tutaj C++ da sobie radę znakomicie:

for (auto &post : json_data["posts"]) {
    string tim = post["tim"];
    string ext = post["ext"];
    auto filename = tim + ext;
}

Bez powtarzania, bez zgadywania typów i bez wątpliwych moralnie operacji (potencjalnie: string + liczba). "Bibliotekę-cud" z takimi operacjami można zmieścić w 400 liniach kodu razem z parsowaniem JSONa.

Ofc jak ktoś woli to można sobie zrobić explicit funkcje typu .str() zamiast konwersji.

Offline bies

  • Użytkownik

# Grudzień 06, 2014, 00:08:35
Jak tu zachowuje się var? Jak auto z C++11 (static inferred typing)?
Tak, z grubsza var == auto, val == const auto.

No ale niekonsekwencję już widzę: w moim kodzie str() jest nie dla ozdoby, tylko dlatego, że post['tim'] to akurat int.
Czyli biblioteka cud przy dodaniu dynamicznego-inta do dynamicznego-stringa zwracałaby jakiegoś stringa?
Tak. Założyłem, że podstawowym typem danych poza obiektem i tablicą będzie string. Więc wszystko będzie miało niejawną konwersję do string (lub u16/u32string). Każdy inny typ trzeba będzie skonwertować albo jakimś json_cast<>()/.int() albo po prostu lexical_cast<>(). To pierwsze wymaga trochę więcej zabawy w implementacji. To trochę inaczej niż pokazuje Dab -- jego wersja będzie równie zwięzła i być może bardziej czytelna.

Czyli chcesz udowodnić, że język typowany statycznie nadaje się do takich rzeczy równie dobrze, co język typowany dynamicznie poprzez... użycie bibliotecznego type erasure w runtime?
Nie udowodnić -- tu nie ma nic do dowodzenia. Przypomnieć. Każdy język ze statycznym typowaniem ma albo również typowanie dynamiczne, albo łatwo je w nim zaimplementować. W drugą stronę to nie działa lub jest o wiele trudniejsze.

Offline Xender

  • Użytkownik

# Grudzień 06, 2014, 00:41:21
Bez powtarzania, bez zgadywania typów i bez wątpliwych moralnie operacji (potencjalnie: string + liczba). "Bibliotekę-cud" z takimi operacjami można zmieścić w 400 liniach kodu razem z parsowaniem JSONa.
Nie wiem, generalnie jestem sceptyczny wobec rzeczy, których nie ma pomimo tego, że teoretycznie prosto można by je zrobić - możliwe scenariusze to "nikt o tym nie pomyślał w ten sposób", albo "to trudniejsze, bo wywala się na przypadkach brzegowych".

Chyba, że biblioteka z takim interfejsem już istnieje.

Każdy język ze statycznym typowaniem ma albo również typowanie dynamiczne, albo łatwo je w nim zaimplementować. W drugą stronę to nie działa lub jest o wiele trudniejsze.
Podstawowe łatwo zrobić, ale trudniej takie, które ma np. introspekcję.
"Zwykła" serializacja w C++ chyba we wszystkich frameworkach, które widziałem, wymagała ręcznego deklarowania pól klasy 2 razy - raz w definicji dla kompilatora, drugi dla bibliotecznego serializatora. Można też pojechać makrami, ale to boli.

Offline ArekBal

  • Użytkownik

# Grudzień 06, 2014, 05:55:20
Alternatywą dla makr może być parsowanie pliku nagłówka.
Coś jak protocol buffers

Offline Xirdus

  • Redaktor

# Grudzień 06, 2014, 11:21:42
Alternatywą dla makr może być parsowanie pliku nagłówka.
Coś jak protocol buffers
Co się sprowadza do zastąpienia jednego preprocesora innym. Osobiście popieram takie coś jeśli drastycznie zmniejsza ilość kodu którą się pisze. Qt-owy moc też tak działa.