🚀 go-pugleaf

Marcin 'Qrczak' Kowalczyk wrote:

>>>Ty uwzględniasz
>>>tylko tę łatwiejszą część.
>>
>>Bo tylko ta część ma dla mnie sens.
> 
> Śmieszne. W źródle na pierwszy rzut oka w ogóle nie widać, które są
> które. Ten podział jest sztuczny, związany z implementacją, a nie
> z tym, co programista chce wyrazić. One są bardzo sensowne, tylko Twój
> ulubiony C++ nie umie ich oferować.

Kwestia punktu siedzenia:

> [...] przy innym języku i innym
> stylu programowania [...]

Właśnie. To co programista chce wyrazić wynika przede wszystkim ze stylu 
programowania. Jeżeli w stylu X nie ma miejsca na konstrukcję Y, to jej 
brak w języku Z nie jest ani defektem ani nawet problemem, jeżeli Z 
służy do X. Powtórzę po raz n-ty: Twój styl i konstrukcje, których 
używasz, nie są uniwersalnie dobre. Fajnie, że istnieją języki, które to 
wspierają (na pewno Ci raźniej ;) ), ale nie oczekuj, że "docelowo" 
wszyscy na to polecą. Różni ludzie mają różne cele.

(W tym kontekście nie ma znaczenia, czy C++ jest "mój ulubiony", czy nie.)

>>>C++ samo się na to skazało przez nieuwzględnienie odśmiecania
>>>i przez przymusowe niszczenie obiektów zawartych w zmiennych
>>>lokalnych, nawet jeśli będą jeszcze potrzebne.
>>
>>Jeśli będą jeszcze potrzebne, to znaczy, że nie są lokalne.
> 
> Nazwy, przez które odwołujemy się do tych obiektów, są lokalne,
> bo nie są globalne. Same obiekty nie potrzebują cechy lokalności
> na poziomie języka.

Owszem, potrzebują, bo lokalność pozwala określić też czas życia 
obiektu. Nazwa obiektu to pikuś - jej lokalność jest fajna, bo nie 
zaśmieca globalnej przestrzeni nazw, ale gdyby tylko o to chodziło, to 
nie byłoby o co się spierać. Czas życia obiektu jest czymś, co jest dla 
mnie kluczowe i pojęcie lokalnoci obiektu związuję z czasem życia a nie 
z widocznością w takim czy innym zasięgu.

Często korzystam z obiektów tymczasowych, które nazwy nie mają a mimo to 
polegam (!) na gwarancjach, które daje mi język w temacie czasu ich 
życia. Bez takich gwarancji pewnych rzeczy w ogóle nie mógłbym wyrazić 
tak, jak chcę.


>>Dostęp do obiektów na zewnątrz funkcji lokalnej mógłby mieć różne
>>formy (przez wartość, przez referencję)
> 
> Wystarczy tylko przez referencję. Dostęp przez wartość jest
> szczególnym przypadkiem dostępu przez referencję, bo to po prostu
> dostęp do innego obiektu, do kopii tego pierwszego.

OK. Wymaga to jednak dodatkowej składni (trzeba coś zrobić, żeby 
stworzyć kopię).

>>i być rozwiązywany w różnym czasie (przy definicji funkcji lub przy
>>jej aplikacji).
> 
> Wystarczy tylko przy definicji. Rozwiązywanie dostępu przy aplikacji
> jest szczególnym przypadkiem dostępu przy definicji, kiedy to zmienna,
> przez którą odwołujemy się do tego obiektu, implementuje dynamiczne
> wiązanie

OK. Ponownie wymaga to dodatkowej składni.
Tak czy inaczej z Twoich "szczególnych" przypadków jednego tematu robią 
się trzy różne składnie.

>>Już takie pobieżne rozpatrzenie tematu daje 3 sensowne możliwości
>>(wartość/kopia ewaluowana w czasie definicji, wartość/kopia
>>ewaluowana w czasie aplikacji, referencja).
> 
> Poproszę tylko trzecią wersję, resztę sobie z niej sam zrobię w razie
> potrzeby.

OK. Podobnie, ja (gdybym miał lambdy takie jak zaproponowałem), przy 
użyciu binderów, mógłbym sobie zrobić "dostęp" z funkcji lokalnych do 
zmiennych na zewnątrz:

void foo()
{
     int local_object;

     bind(
         void (int i) { cout << i; },  // lambda z jednym parametrem
         local_object                  // dowiązanie local_object do i
     )();                              // aplikacja obiektu funkcyjnego
}

Funkcja bind bierze obiekt funkcyjny (tutaj lambdę z jednym parametrem) 
i obiekt local_object, oraz zwraca nowy obiekt funkcyjny o zredukowanej 
arności. Na końcu jest aplikacja wynikowego obiektu funkcyjnego, ale 
można by go też przekazać gdzie indziej.

Oczywiście, można też tak:

void (int i) { cout << i; } (local_object);

ale nie o to mi tutaj chodzi - binder pozwala stworzyć funkcję 
*bezparametrową*, która ma "dostęp" do local_object, bez zakłocania jego 
czasu życia.

Spodziewam się, że local_object jest kopiowany w momencie utworzenia 
obiektu z bindera. Zamiast int być też shared_ptr albo inny twór, jeśli 
komuś zależy na przedłużeniu czasu życia obiektu poza zakres, gdzie był 
stworzony.

*Nie ma* tu formalnie dostępu z funkcji lokalnej do obiektów na 
zewnątrz. Całość jest niewątpliwie dłuższa, niż np.:

void foo()
{
     int local_object;

     void () { cout << local_object; } ();
}

ale właśnie wolę przy takich rzeczach mieć więcej rzeczy zrobionych jawnie.

Oczywiście, local_object ma *skończyć życie* przy wyjściu z foo(). Nie 
ma prawa żyć dłużej, niż trwa wykonywanie foo().


> Z tego, że niektórzy wciąż się łudzą, że w C++ da się to zrobić, nie
> wynika, że to prawda. Wymagałoby to zbyt dużego odejścia od założeń C++

I właśnie tu robisz błąd, bo nie zauważasz, że to jest sprawa względna.
Prawdą jest, że Twój model (w odróżnieniu od tego, co pokazałem wyżej) 
wymaga "dużego odejścia od *założeń* C++". Można z tego wyciągnąć dwa 
różne wnioski:

1. Założenia C++ są do bani, bo nie pasują do Twojego ulubionego modelu.
2. Twój ulubiony model jest do bani, bo nie pasuje do założeń C++ (i np. 
Ady i całej masy języków, które przyjęły podobne założenia).

Akurat przyjąłeś wersję 1.

Powiem po raz (n+1)-szy: Twój model nie jest uniwersalny i nie trafia w 
oczekiwania *wszystkich* programistów.


>>Pytanie, czy to jest potrzebne. Nie w sensie teoretycznym
>>(czyli: mamy paru gości, którzy się świetnie bawią i piszą na ten
>>temat artykuły), ale praktycznym (czyli: używamy tego w realnych
>>projektach, z realnymi procesami i standardami kodowania).
> 
> Co to znaczy "potrzebne"? Nie jest niezbędne. Jest przydatne.
> Jak to zwykle z konstrukcjami językowymi bywa.

Większa część Perla składa się z rzeczy, które ktoś uznał za przydatne. :)


>>>Model C++ jest zakonserwowany w C++, a poza tym martwy
> 
>>Ada ma taki sam model.

> I te języki powinny pozostać do specjalizowanych zastosowań: mocno
> ograniczonych zasobów i hard real time wymagań, kiedy nie możemy sobie
> pozwolić na luksusy wygodnych konstrukcji, tylko musimy pilnować
> zasobów zużywanych przez każdą operację.

Nie. To nie ma związku z zasobami, tylko z tym, jakie pojęcia związujesz 
z koncepcją obiektu. Ja z koncepcją obiektu związuję pojęcie czasu 
życia. Nie interesują mnie tricki, przy których miałbym w tym temacie 
jakieś wątpliwości.

Taki styl.


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