🚀 go-pugleaf

Maciej Sobczak <no.spam@no.spam.com> writes:

>> To się nie skaluje do większych przykładów. Listowanie zmiennych
>> wolnych każdej lokalnej funkcji będzie przykre.
>
> I bardzo dobrze! O to właśnie chodzi, dokładnie tak samo jak z
> reinterpret_cast, static_cast, itd. - one też się nie "skalują" do
> większych przykładów. To *ma* wystawać z kodu i być widoczne.

Po co język ma do tego zniechęcać? Do reinterpret_cast rozumiem,
niech zniechęca, ale do lokalnych funkcji - nie.

Wyróżniać się powinny przede wszystkim operacje, które mają zachowanie
niezdefiniowane albo bardzo trudno przewidywalne, kiedy się ich źle
użyje. Tyle że w C++ jest ich za dużo, żeby to było praktyczne.

> A w sytuacji, gdy programista zrobi potwora na 20 takich zmiennych,
> to ma być wskazówką, że robi coś podejrzanego, bo np. usiłuje
> stworzyć kod zupełnie pozbawiony struktury.

Mój kod używa 7 zmiennych i koncepcyjnie nie jest potworny, a w C++
z Twoją hipotetyczną biblioteką wygląda potwornie. W czystym C++
wyglądałby jeszcze gorzej.

N zmiennych używanych przez funkcję lokalną jest tak samo potworne
albo niepoworne jak N zwykłych zmiennych lokalnych.

W tym przypadku sens lokalnych funkcji jest taki, że wynik części
instrukcji ma być wsadzony do środka wyniku pewnej zwykłej funkcji,
w miejsce zadecydowane przez ową funkcję. Ona nie tylko decyduje
o miejscu, ale też podaje pewnien parametr tym instrukcjom. Zatem
instrukcje są wyrażone lokalną funkcją, która jest przekazywana przez
argument do tamtej. Ten schemat jest użyty trzy razy w jednym miejscu.
Oczywiście wewnętrzne instrukcje używają parametrów funkcji, w której
to wszystko się dzieje, i jej zmiennych lokalnych.

> Jeżeli sam nie ma hamulców, to może chociaż dostanie po łapach
> podczas code review od kogoś, kto to będzie musiał przeczytać
> i zrozumieć.

Jasne, jeździjmy po ulicach z włączonym ręcznym. Hamulec - niech
będzie, ale tylko kiedy robię coś niestosownego, a nie cały czas.
Ograniczenie bardziej by się przydało przy guziku "autodestrukcja",
a tutaj akurat w C++ go brakuje.

>> Fajne, nie?
>
> Super. I co to pokazuje?

Że Twoja proteza nie pozwala stwierdzić, że C++ wspiera lokalne
funkcje. W języku, który je normalnie wspiera, są nieporównywalnie
wygodniejsze w użyciu niż przy pomocy Twojej konstrukcji. Różnica
w czytelności jest tak duża, że jedno rozwiązanie jest akceptowalne,
a drugie nie.

Czyli C++ z Twoim rozwiązaniem jeśli się uprzeć, to spełnia literę
wymagań, ale w taki sposób, że jest to prawie bezużyteczne. Powinieneś
być politykiem.

> Problem z tym przykładem polega na tym, że usiłujesz swój model
> wyrazić w C++ - koncentrujesz się na środkach a nie na celach.
> Gdybyś koncentrował się na celach, to zauważyłbyś, że wiele
> kompilatorów i translatorów było pisanych w C++ (i w czymkolwiek
> innym) i nikt takiej sieczki tam nie napisał (pomijając to, że
> w C++ nie ma lambdy).

Wypraszam sobie, oryginalny kod w moim języku nie był sieczką.

Oczywiście że można całość wyrazić całkiem inaczej. Ale dlaczego
miałbym być do tego zmuszony przez ograniczenia języka? Uważam mój
schemat za zgrabny, tylko C++ nie pozwala mi go sensownie zapisać.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/