🚀 go-pugleaf

Marcin 'Qrczak' Kowalczyk wrote:

>>Najlepsze rozwiązanie jakie do tej pory widziałem to etykiety pętli.
> 
> Nadaje się tylko do wbudowanych w składnię języka rodzajów pętli
> i tylko kiedy pętla i miejsce przerwania znajdują się w tej samej
> funkcji.

Zgadza się. Przerywanie pętli jest wtedy częścią "gramatyki" tej pętli, 
podobnie jak obecnie samo 'break' - to tylko nadzbiór tej koncepcji.
Wydaje mi się to sensowne, bo przerwanie pętli (i kontynuację dalszej 
części kodu w tym samym zakresie!) traktuję jako logiczną część 
sterowania pętli a nie jako protezę ulepioną z innych mechanizmów języka 
(np. z wyjątków). Tak właśnie działa samo 'break' w C/C++.

> Nie nadaje się, kiedy pętle są realizowane lokalnymi
> funkcjami.

Zgadza się. Jeżeli wszystko (łącznie ze strukturami sterującymi) 
sprowadzisz strukturalnie do funkcji, to dalej musisz konsekwentnie 
posługiwać się takimi mechanizmami, które są wtedy dostępne. Tylko że 
wtedy te mechanizmy nie są dobre przez ich obiektywną wyższość nad czymś 
innym, tylko po prostu inaczej się nie da.

Dostępność etykiet pętli w języku nie wyklucza stosowania wyjątków do 
czegokolwiek. Wtedy można jawnie wyrazić intencje używając przerwania 
pętli do przerwania pętli a wyjątków do wyjątków.


>>Od wyjątków różni się dodatkowo tym, że nie można tego schować
>>w funkcji wywołanej w pętli, ale akurat nie uważam tego za wadę.
> 
> A ja uważam.

Schowanie czegoś w funkcji (nie mówię o lambdach, tylko o nazwanych 
funkcjach) powoduje taki problem, że można tą funkcję wykorzystać z 
innego kontekstu, gdzie może nie być żadnej pętli do przerwania. Nie 
należy odrywać mechanizmu przerwania pętli od mechanizmu pętli, bo to 
utrudnia pielęgnację kodu.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/