🚀 go-pugleaf

Maciej Sobczak wrote:
> Etam, Seweryn, dałeś się wkręcić. To jest Naciąganie Gaci Przez Głowę
> (tm).

Może i jest. A może nie... nie będę się kłócił.

> class ClassForNormalUse
> {
> public:
>     void doThis();
>     void doThat();
> };
> 
> class ClassWithAdditionalFeaturesForInitialization : public
> ClassForNormalUse
> {
> public:
>     void readConfigFiles();
>     void doSomethingSpecialAtTheBeginning();
> };
> 
> ClassForNormalUse & getIt()
> {
>     static ClassWithAdditionalFeaturesForInitialization x;
> 
>     x.readConfigFiles();
>     x.doSomethingSpecialAtTheBeginning();
> 
>     // ok, object is ready for normal use:
>     return x;
> }
> 
> // ...
> 
> ClassForNormalUse & x = getIt();
> 
> x.doThis();
> x.doThat();
> x.readConfigFiles(); // WTF? no such method (in compile-time!)
> 
> 
> Nie trzeba kasować metod ze słownika, żeby podzielić funkcjonalność
> czegoś na etapy.

Tylko, że ten podział, żeby być skutecznym, musi przebiegać po granicy 
wywoałania getIt(), co może być bardzo nienaturalne. Co gorsza getIt() można 
zawołać tysiące razy, również pod koniec działania programu. Nie masz tu 
żadnego nmechanizmu zabraniającego zastosowanie 
ClassWithAdditionalFeaturesForInitialization również w czasie absolutnie z 
inicjalizacją nie związanym.


Modyfikacja klasy przez usunięcie z niej metody zmienia typ. Czyli do pewnej 
chwili działania programu mamy jakiś typ, ale po tem jest już typ inny. I 
wszystkie (nawet tysiące) instancji typu pierwszego zostaje jednym 
pociągnięciem zamienionych w instancje typu drugiego (i np. stają się 
immutable).

Występowanie w programach zmiennych stałych, czyli obiektów które w czasie 
normalnego działania programu są stałymi, ale na jego początku muszą zostać 
zainicjowane na podstawie danych zewnętrznych.

> Wieloetapowość można naturalnie wyrazić ze statycznym systemem typów
> posługując się różnymi widokami na ten sam obiekt w różnych chwilach
> jego życia.

Ale musisz się zajmować każdym obiektem z osobna co jest uciążliwe. A tu 
mówimy o życiu całej aplikacji a nie jednego obiektu.

> I nie, nie trzeba tego opisywać jako "zagadnienie dla zaawansowanych",
> bo już samo to określenie pokazuje, że kasowanie metod to zwykłe
> Naciąganie Gaci Przez Głowę (tm).

To samo określenie nic nie pokazjue. Ale taka konstrukcja jest w Pythonie 
stosowana niezwykle rzadko. Zapewne dlatego, że dla normalnych ludzi 
wystarcza konwencja (np nazwa z samych wielkich liter oznacza stałą lub 
właśnie zmienną stałą). Wymuszanie czegoś takiego to pomysł bardziej 
ceplusplusiczny(tm) a nie pytoniczny.

pzdr
\SK