Seweryn Habdank-Wojewódzki wrote:
>> type 'a tree = Leaf | Node of 'a * 'a tree * 'a tree
>
>> zmieni. A jeśli zmieni, to znaczy, że przegrał, bo zmienia w ten
>> sposób fundamentalny aparat pojęciowy.
>
> Ale mowa o wizytatorze i rozwijajaczym sie drzewie klas.
> W ogole nie przystaje do mojego przypadku. z klasami rozwijajacymi
> sie.
> W kwestii wspomnianego wizytatora nie masz ograniczen projektowych.

Masz. Każde dodanie nowej odwiedzanej klasy wymaga zmianę *wszystkich*
wizytatorów. Inaczej się nie skompiluje. Kropka.

> A co to ma do rzeczy? Pisalem, ze uwazam ze w C++, to byloby chore.

Chcesz powiedzieć, że C++ jest chore? W końcu doznałeś Oświecenia! ;)

> Dla ustalenia uwagi. rozwalanie kompilacji (poprzez rzucanie bledu bo
> jakas
> klasa jest nieobsluzona).

Och. W przypadku Wizytatora kompilacja się rozwala gdy jakaś klasa jest
nieobsłużona. Mówisz to jest chore. A że to jest C++, to C++ jest chore.
You see the light!!! ;))) (co prazwda z dziwnej storny, ale czyż nie efekt
jest ważny? Radość z hjednego nawróconego...)

pzdr

Dnia 03.07.2008 Sebastian Kaliszewski <s.usun.to> napisał/a:

> Och. W przypadku Wizytatora kompilacja się rozwala gdy jakaś klasa jest
> nieobsłużona. Mówisz to jest chore. A że to jest C++, to C++ jest chore.
> You see the light!!! ;))) (co prazwda z dziwnej storny, ale czyż nie efekt
> jest ważny? Radość z hjednego nawróconego...)

Etam. Mnie nienawróceni są nawet na rękę: im więcej jest ludzi, którzy
z uporem maniaka używają narzędzia wymuszającego wielokrotnie większy nakład
pracy, niż Lepszy I Skuteczniejszy Programming-language, tym bardziej jestem
konkurencyjny. I dlatego staram się nie tracić czasu na flejmy -- jest tyle
ciekawych problemów do pracy nad :)

Witam

> Raz
> zapomniałem o słowach "lub czasop.." ee "lub błędzie" i już
> się czepiasz :).

Więcej niż raz, bo w pewnym momencie to się zrobił stan domyślany..
TAK! Czepiam się.

> Zresztą nie o to chodzi. Chodzi o sam fakt,
> że kompilator zasygnalizował potencjalne problemy. U mnie
> domyślnie ostrzeżenie kończy się błędem kompilacji.

A kompilowałeś,boosta? Np. lexical_cast? Wiesz jaka chorda ostrzezeń
tam pada.
Szczegolnie pojawiają się takie, ktore wynikają z konkretyzacji dla
określonego typu.
W zasadzie nie widzę, aby je się łatwo poprawiało.

> A po co miałby się przejmować. Pokazujesz niepowiązanie ze
> sobą problemy. Tam nie ma potrzeby stosowanie tam typów
> wariantowych.

Hmm... To może obrazek.

Masz program symulacyjny, gdzie w wezlach grafu siedza algorytmy
a krawędzie są odpowiedzialne za przekazywanie okreslonego stanu.
Zobacz na pakiet Simulink z Matlaba.

Aby policzyć symulacje należy wykonać wizytację każdego węzła,
co więcej trzeba to wykonać zgodnie z kierunkami krawędzi.

Celowo nie używal pojęcia Wizytator (patrz post z dopiskiem -
Wizytator).

Zatem taka symulacja jak najbardziej pasuje do zadania wizytowania,
możesz mieć algorytmy. Co więcej moga one być lokalnie modyfikowane,
Np. jesli typ wchodzacy jest bool, to pula dostepnych algorytmow
sprowadza sie
jedynie do takich co obsługują bool, lub ewentualnie moga byc rzucone
na bool.
Np. wektor dwu wymiarowy nie podpada pod to.
Dlaczego zatem mając algorytm dla wektorow wezeł obsługujący boole ma
sie
nim przejmować?

Pozdrawiam,
Seweryn Habdank-Wojewódzki.

Witam

> Widać mało co zrozumiałeś. Przeczytaj jeszcze raz!!!
> 2. Bredzisz, bo najwyraźniej w ogóle nie rozumiesz o co chodzi.
> Seweryn. Jeszcze raz... Sio, przeczytaj ze zrozumeiniem o wzorcu Visitor,
> Wygląda, że nic, ale to absolutnie nic, z całego tego wątku nie
> zrozumiałeś...
> Tego pomysłu wogóle nie rozumiesz. W ogóle nie wiesz o co biega. MArsz
> przeczytać jeszcze raz całość. Tym razem ze zrozumieniem.

Tyle razy powiedziałeś, że nic nie kapuję, że jestem skory w to
uwierzyć :-).

> Seweryn, zachowujesz się jak ta blondynak jadąc pod prąd po autostradzie.
> Zobacz, wszycy są zgodnie -- Maciek, Qrczak, Krzysiek i nawet ja. Pomyśl:
> coś w tym może jednak jest, czegoś nie zauważyłeś...

Odpowiem zbiorowo w innym poście. Odnoszę wrażenie, że niezrozumienie
jest pomiędzy nami.

Pozdrawiam,
Seweryn Habdank-Wojewódzki.

Witam

> Znaczy wyskoczyłeś z tą Scalą i Pythonem jak Filip z konopii.

Nie ja zacząłem :-)!

Zapytałem "BTW" jak te języki mają się do siebie. Zapytałem również
jaką
wartość dodaną oferuje skala względem J(P)ythona.

Temat Scali pojawił się bardzo wcześnie.

Pozdrawiam,
Seweryn Habdank-Wojewódzki,

Witam

> Masz. Każde dodanie nowej odwiedzanej klasy wymaga zmianę *wszystkich*
> wizytatorów. Inaczej się nie skompiluje. Kropka.

E... O czym Ty mówisz? Czy możesz jaśniej?

> Och. W przypadku Wizytatora kompilacja się rozwala gdy jakaś klasa jest
> nieobsłużona. Mówisz to jest chore. A że to jest C++, to C++ jestchore.

Teraz to już nic nie rozumiem.

Pozdrawiam,
Seweryn Habdank-Wojewodzki.

Witam

[kometarz: odpowiadam Tobie, ale odpowiedź kieruję do wszystkich]

Jakie mam podejście do Wizytatora. Uważam, że jest to dywan, i to dość dziurawy,
pod który chowa się błędy projektowe (bardziej dosadnie określam to na końcu
postu).

W publikacji [1] pada stwierdzenie:

"With the above issues in mind, the Visitor is not really
a design pattern - rather just a language idiom. Most often over-emphasized."

Jeżeli istnieje wspólny interfejs klas, które mają być wizytowane
to nie ma problemu. Kolekcja po której wędruje iterator
może być oparta na wspólnym interfejsie. Nie ma potrzeby istnienia,
żadnego switch, dlatego, że każda klasa ma wspólny interfejs.

Wystarczy for () {it->method()}

Weźmy przykład z artykułu:

class DoSomethingVisitor : public Visitor
{
public:
void visit(Hammer & h)
{
// do something with the hammer
}

void visit(Drill & d)
{
// do something with the drill
}

void visit(Saw & s)
{
// do something with the saw
}
};

Jeżeli za "// do something with the saw" kryje się,
np. use albo whatever, to nie potrzeba
mieć tego switch, bo KAŻDY Tool ma albo USE albo WHATEVER.
Przy czym zakładam, że Tool : public /*,np.*/ Usable.

Uwaga! Jeżeli tak nie jest, to uważam, że projekt jest do poprawy
(lub czytaj dalej).

Jeżeli jest tak, że metody przyjmują jakieś x,y a inne z,q i one
są różnych typów, to jest również do korekty projektowej.

Są dwie + jeden metod poprawy projektu.

Zacznę o podejścia dynamicznego.

Klasy mają jakieś metody, które wyglądają jak USE, ale należy
z nimi popracować. Tutaj pojawia się IMHO wzorzec adapter,
który zawiera referencję do klasy właściwej i porządkuje
API klasy, tak aby pojawiła się, np. metoda USE.

Nie zaburzam enkapsulacji. Tworzę interfejs USABLE.
Tworzę adaptery : public USABLE tak aby zawierały uporządkowane
sprawy każdej (np. legacy) klasy, która jest USABLE-like ale nie
jest USABLE.

Następnie kolekcja zawiera USABLE*. I mogę wołać po prostu:

it->use(...)

NIE POTRZEBUJE SWITCH!!!

Kiedy parametry są jakieś niepasujące. To znaczy jedna klasa
wymaga int druga string.

Wyjście:

Opakować parametry w klasę boost::any, DynamicAny, whatever.
Może być boost:variant, który jest bardziej restrykcyjny niż boost::any.

Jeśli stan jest bardziej homogeniczny to lepiej mieć własny typ MyParam.
Dedykowany do przesłania parametrów ogólnych, ale dobrze określonych,
np.tylko int i string. W brew pozorom to nie jest złe
rozwiązanie. Co więcej zazwyczaj problemy są nie z typami skomplikowanymi,
a z typami prostymi jak double, int, czy char*, a tych nie jest wiele.

Mając to znowu nie potrzebuję switch do pracy z typem zewnetrznym, co najwyzej
jakis switch jest w konkretnej klasie przy obsłudze MyParams. Bo:

it->use(MyParam const & m) lub inne

Alternatywa:

Jeżeli jest jakieś specjalne bardzo pokręcone zachowanie.
Rozważam (i o tym pisałem) zastosowanie listy typów.

I statyczną iterację po typach. Oraz wykonanie jakichś funkcji
z zestawu funkcji, pobierających statycznie określony typ.

use (Hammer & t, What & w), use(Axe & a, What & w).

A w nich:
use (Hammer & t, What & w) {/*&Hammer::*/t.bij(w)}
use (Axe & a, What & w) {/*&Axe::*/a.siecz(w)}
use (Młotek & m, Kotek & k) { m.pieprz (k)}
(i one mogę być elegancko przeładowane, czy jak to się nazywa).

Jeżeli mam listę typów, np. boost::tuple mytuple tuple<Hammer, Axe>.
To mogę wykonać coś ala

boost::tuple_for_each <mytuple> (use(...)).

Chwilowo nie mam Karlssona, a nie pamiętam składni for_each dla tuple,
ale idea jest chyba jasna.

W każdym razie znowu nie mam switch po typach odwiedzanych.

Natomiast zaleta jest taka, ze jeśli te klasy czy są powiązane,
czy nie, pracują razem mając ustalone API. Nie mam śmietnika.
Jeśli jest śmietnik, porządkuję go. Porządkuję (Adapter), a nie
zamiatam dziadostwo pod dywan (Wizytor).

Adapterem nazywam zarówno stworzenie klasy USABLE i dziedziczenie
adaptera zawierającego referencję z USABLE,
jak i stworzenie funkcji use (Tool & t, What & w).
Oba podejścia to dla mnie adaptery.

I tu przechodzę do sedna, padło określenie:

"Ponieważ wizytor to językowy idiom, wprowadzony po to aby
ominąć ograniczenia np.: C++ i Javy."

Wizytor to nie jest lekarstwo na braki w języku.
To jest dziurawa przykrywka na śmietnik w kodzie i w projekcie.
Dziurawa i dlatego potrzeba w switch'u:

"the lack of appropriate guarantee from the switch statement is
only a deficiency of the particular language"

Padło również określenie:

"Zastanawiałem
się czy inni grupowicze, odczuwali potrzebę takiej
konstrukcji w C++. Ewentualnie ktoś coś może słyszał, że
były takie propozycje w przyszłej wersji standardu."

Komitet, który szanuję, ma wystarczająco dużo problemów,
aby zajmować się śmietnikiem w moim kodzie. Dlatego
NIE uważam, że komitet ma zająć się poprawą switch'a
tylko dlatego, że Wizytator będąc słabym wzorcem
projektowym, którego trzeba łatać switchem, a to wymaga poprawy
switcha.

To co do tej pory miałem, to nie potrzebowałem switcha
do wizytacji. Wizytacja dla mnie nie koniecznie wiąże się
z użyciem wizytora.

Przykładowo dla mnie kod:

Cytuję:

void bar()
{
// tu mam w polu widzenia x, y, z, t, u, v, itd. RÓŻNYCH typów
switch ( e.Type )
{
case Type.UnaryExpression:
zrób coś z x, y i z;
case Type.BinaryExpression:
zrób coś z u, v;
}
}

To jest kod do re-faktoringu. Wewnątrz funkcji obserwuję koktajl.
Jeżeli dostaję jakiś obiekt (nie wiem jaki bo typ ustalam w locie),
do tego wywołuję go raz z parametrami x,y,z a raz z u,v
I jeszcze na domiar złego niech raz to będzie metoda "eval" a raz use.
To już w ogóle zastanawiam się czy może wcześniej nie było tak
/*global*/ void* e, tym bardziej, że bar(/*void*/),
a "e" przychodzi nie wiem skąd -- może global scope?.

Mam ograniczone doświadczenie, ale do tej pory nie spotkałem się
z sytuacją, kiedy nie dało się tego uporządkować, adaptery + MyParams.
Chodzi mi cały czas o pełną enkapsulację.

Nie zgadzam się z określeniem "deficiencies in the language" w treści
(patrz dalej):

"In this case, instead of stating that the Visitor pattern is good
because C++ and Java have deficient switch control structure, it
would be better to state that it is a pity that the deficiencies
in the language lead programmers to use poor patterns"

C++ i Java mają wady, ale czy brak kontroli switch w kontekście Wizytatora,
do jest "deficiency"? Poza tym Qrczak już powiedział, że, np. GCC
oferuje tą usługę i widać, że nie potrzebowała ona wynikać z języka,
ale jest traktowana jako ficzer kompilatora. To całkiem zmienia
kłopotliwość tej usługi, co więcej to jest realizowane przez warning.
A standard nie rozróżnia pojęcia warning i error (wypowiedz Sebastiana).
Dodatkowo ta właśność kompilatora w zgledem switch jest słaba.
Jeśli ktoś zamiast switch w obsłudze Wizytatora użyje
if (){} else if(){} ... to co? Jak to zostanie sprawdzone?
Ciekawy ten wzorzec, że miałby tylko jedyną słuszną implementację
poprzez użycie switch -- to nawet wzkaźników jest kilka rodzai.

Padło tez pytanie:

"a najgorsze, w tym wszystkim, że niektóre języki nie mają
preprocesora, jak w tym pisać?"

W Javie nie pozostaje nic innego, jak używać USABLE, ale tam takie
podejście jest bardzo powszechne i nie budzi żadnych zastrzeżeń.
W C++ jest wybór USABLE albo use(Tool & t,...)

Podsumowując posłużę się ordynarnym stwierdzeniem.

Wizytator jest jak burdel w mieście.
A język jest jak miasto, w prawie kazdym mieście
można otworzyć miejsce "wątpliwej przyjemności i niewątpliwej rzeżączki"
(A. Sapkowski).

Gdyby w kodzie był porządek to wizytator nie jest potrzebny.

Natomiast proces odwiedzania (przychodzenia w gości) jest bardzo
potrzebny z wielu społecznych i ekonomicznych względów.
Ale odwiedzanie nie koniecznie wiąże się z burdelem.

Odwiedzanie kojarzy się z kulturą, obyciem i wspólnym językiem.
A zatem wspólny język to wspólne API.
Porządek to albo drzewo klas albo lista typów.
A obycie to dopasowanie się do otoczenia, czyli adaptery
i klasy wrapujące parametry.

Czy odwiedzając noworoczną galę przychodzi się w glanach
i popija wódę z gwinta klepiąc po "pupach" kobiety?

Nie! Każdy przychodzi w smokingu (adapter), pije się z kieliszków
(klasy wrapujące parametry). A klepanie po "pupach" zostawia się na
później. Jeśli ktoś musi (już teraz), to będzie to robił solo ze swoją
partnerką. A nie w miejscu odwiedzanym (na gali).
Jeśli musi w czasie (a nie na) gali, to musi posłużyć się takim sposobem
(adapterem), który spowoduje, że żaden paparazzi nie przyłapie go na tym.
Są na to sposoby przeładowanie metod lub funkcji, dedykowane adaptery
i inne szwindle. Ale to jest wykonywane w ukryciu (enkapsulacja)
i dotyczy tylko napalonego Pana XYZ.
A nie, że wszyscy na gali muszą w tym uczestniczyć.

Rozumiem, że do programowania dziś przenika styl życia naszych
milusińskich ze sfery szołbyznesu. I każdy odwiedzający galę
chce się wykazać indywidualnością i nowym sposobem na skandal,
ale to chyba nie jest coś do czego dążymy w programowaniu.

A jeśli ktoś uważa, że przygotowanie eleganckiej gali i jej uczestników jest:

"uporem maniaka ... wymuszającego wielokrotnie większy nakład
pracy, niż Lepszy I Skuteczniejszy Programming-language, tym bardziej jestem
konkurencyjny."

To się myli. W każdym języku jest taki moment, że kończy się język zaczyna się
architektura, smak, wyczucie.

Z resztą obserwuję co następuje:
(Junior) Software Developer, Senior (Experienced) Software Developer,
(Junior) Software Architect, Senior (Experienced) Software Architect.

Problemy z odwiedzaniem to są mikro problemy w porównaniu z Concurency Computing,
Distributed Systems, Hardware Integration itd. A tak się składa, że jak Jasia
nie nauczą sprzątać swoich 2m^2 zabawek, to nie nauczy się sprzątać M5.

Jak język załatwi za niego wizytację (niania ubierze go na galę), to on sam
nie będzie umiał gali zorganizować rozesłać zaproszeń i odebrać potwierdzeń
(distributed system), zorganizować: taksówki, lokaji, sprawnej kuchni,
muzyki i innych (paraller computing).

Ze swojej strony życzę powodzenia w używaniu "Skuteczniejszy
Programming-language".

Czekam jak powstanie "Skuteczniejszy Programming-language", który
oferuje naprawdę wiele.

A co do konkurencyjności na rynku pracy to jak się ją mierzy?
W liczbie ofert opracy czy w oferowanych:
(kwotach + bonusy) / średnia pensja w danym mieście?
Czy jeszcze inaczej?

Pozdrawiam,
Seweryn Habdank-Wojewódzki.

[1] http://www.inspirel.com/articles/Visitor_Revisited.html

Witam

> W normalnych językach nie ma headerów.

Prawdziwe jest stwierdzenie:
Nie we wszystkich językach są headery.

> BTW. po czym dziedziczy D?

Po A albo po niczym.

> > 2. Nawet jesli includuje klasę D, to dlaczego projekt
> > ma sie nie kompilowac w 1000 miejscach, bo ja sobie
> > napisalem klasę D.
>
> Takie jest zadanie statycznego systemu typów.

Nie. Przykład:

class Foo;
class Bar;

typedef ::boost::shared_ptr<Foo> Foo_ptr;
Foo_ptr foo_ptr;

Nie mam problemów z kompilacją.

> Sewryn, przeczytaj w końcu o tym wizytatorze. *Ze zrozumieniem*!

OK. Przeczytam.

> W tym Wizytatorze masz Dokładnie to Samo(tm). Tylko, że więcej kodu i kod
> jest porozrzucany po różnych miejscach.

To nie jest wizytator. To jest gniot na rządanie.

> Przeczytaj jeszcze raz o Idiomie Wizytator ( (c) Maciek Sobczak).

OK.To już drugi raz.

> >Czyli nie wychodze
> > przez tydzien z pracy do domu, bo Xiński napisał klasę,
> > a ja weekend mam zamknąc wersją ktora się kompiluje.
>
> Komililuje ale nie działa? Ciekawe...

Nie działa w sensie, że nie jest używana (aktywnie).

> BTW. to jest problem zarządzania wersjami. Jak jest do kitu to "Święty Boże
> nie pomoże"...

Dla mnie do kitu to jest wizytator robiony switchem.

> BTW2. Przeczytaj jeszcze raz o Idiomie Wizytator ( (c) Maciek Sobczak).

OK. To już poraz trzeci. Noc przede mną.

> Przeczytaj jescze raz o Idiomie Wizytator ( (c) Maciek Sobczak). Tu jest to
> samo :)

Po raz czwarty? Jak ja do pracy wstanę?

> > Oby nie.
>
> Oby tak.

Czy standard C++ ma się zajmować problemem AIDS w EU?

> "Wzorzec" Wizytator stwarza dokłądnie takie same problemy!

Ja się zgadzam z Maćkiem, że Wizytator to jest błąd u samej podstawy.
I tu jest problem. Z fałszu wynika wszystko. Każdy język jest
do bani, który nie wspiera tego pseudo-wzorca.

> Oh, wzorzec wizytator jest zatem karygodny :)

Tak i nie. To jest sygnał na re-faktoryzacji.

Pozdrawiam,
Seweryn Habdank-Wojewodzki.

Sebastian Kaliszewski <s.usun.to> writes:

> Seweryn Habdank-Wojewodzki wrote:
>
> W normalnych jezykach nie ma headerów.

Jeszcze gorzej ;)

> BTW. po czym dziedziczy D?
>

Moze rozwine - co jeśli A, B i C znajdują sie w bibliotece libtools.so
(tools.dll) a D w pliku wykonywalnym app (app.exe)?

a) Zabronic tego typu rzeczy, zrezygnowac z kompatybilności wstecz
i wiekszośc kodu wrzucic do /dev/null. Oczywiście trzeba jakoś zintegrowac
linker z kompilatorem...
b) Skupic sie na warringach dla A, B i C cicho milcząc na temat D (o którym
nie wiemy) i to w dodatku w czasie linkowania najpewniej (dowidzenia wszystkie
dotychczasowe kompilatory i linkery)
c) Zrobic to w linkerze i obserwowac kompilując app czy takie przypadki nie
wystepują (wspaniale - szukanie 'bledów' w cudzej bibliotece nie na poziomie
API/ABI)
d) Inne?

Pozdrawiam

Seweryn Habdank-Wojewódzki wrote:
>> Znaczy wyskoczyłeś z tą Scalą i Pythonem jak Filip z konopii.
>
> Nie ja zacząłem :-)!
>
> Zapytałem "BTW" jak te języki mają się do siebie.

Odpowiadam: są dość istotnie różne (statyuczny vs dynamiczny, składnia,
itd...)

pzdr

Witam

> > Zapytałem "BTW" jak te języki mają się do siebie.
>
> Odpowiadam: są dość istotnie różne (statyuczny vs dynamiczny, składnia,
> itd...)

Sebastian, z calym szacunkiem, ale czy to nie Ty porownywales Pythona
i C++.

To samo mozna powiedziec -- są dość istotnie różne (statyczny vs
dynamiczny,
składnia, itd...)

A zatem rozumiem, ze juz wiecej nie bedziesz porownywal C++ i Pythona,
bo
ich relacja jest wg. Ciebie taka, ze nie ma co porownywac.

Ah jak ja sie ciesze, ze zapanuje blogi spokoj nie porownywania, ale
jakby porownywania.

Pozdrawiam,
Seweryn Habdank-Wojewodzki.

Seweryn Habdank-Wojewódzki wrote:
>> > Zapytalem "BTW" jak te jezyki mają sie do siebie.
>>
>> Odpowiadam: są dośc istotnie rózne (statyuczny vs dynamiczny, skladnia,
>> itd...)
>
> Sebastian, z calym szacunkiem, ale czy to nie Ty porownywales Pythona
> i C++.

Ale o co ci chodzi?

Porównuje ich rózne aspekty.


> To samo mozna powiedziec -- są dośc istotnie rózne (statyczny vs
> dynamiczny,
> skladnia, itd...)

No i są. I tu i tu odpowiedL dobra. Nie znam Scali tak, zeby ją specjalnie
chwalic albo specjalnie krytykowac. C++ jak najbardziej znam.


> A zatem rozumiem, ze juz wiecej nie bedziesz porownywal C++ i Pythona,
> bo ich relacja jest wg. Ciebie taka, ze nie ma co porownywac.

Nic nigdzie takiego nie napisalem. Nie imputuj mi.


> Ah jak ja sie ciesze, ze zapanuje blogi spokoj nie porownywania, ale
> jakby porownywania.

Nie zapanuje. Ja mam zwyczaj chwalic / krytykowac to co znam. C++ znam
wiec... :)

pzdr

Seweryn Habdank-Wojewodzki wrote:

[..]
> "With the above issues in mind, the Visitor is not really
> a design pattern - rather just a language idiom. Most often
> over-emphasized."
>
> Jezeli istnieje wspólny interfejs klas, które mają byc wizytowane
> to nie ma problemu. Kolekcja po której wedruje iterator
> moze byc oparta na wspólnym interfejsie. Nie ma potrzeby istnienia,
> zadnego switch, dlatego, ze kazda klasa ma wspólny interfejs.
>
> Wystarczy for () {it->method()}

Twój świat jest plaski. Jeśli wyjdziesz jednak poza plaskie struktury typu
mapa, lista, macierz czy wektor to czesto masz tak ze nie tylko obiekty sie
róznią, ale zaleznie od typu rózne są ich relacje z innymi elementami tej
samej struktury. Tak jest chocby w drzewie wyprowadzenia czy abstrakcyjnym
drzewie skladni programu.

[...]
> Uwaga! Jezeli tak nie jest, to uwazam, ze projekt jest do poprawy

W wielu wypadkach taka jest natura problemu. Projekt jest dobry a wszelkei
inne kombinacje prowadzą do projektu gorszego.

> (lub czytaj dalej).
>
> Jezeli jest tak, ze metody przyjmują jakieś x,y a inne z,q i one
> są róznych typów, to jest równiez do korekty projektowej.

Nie. Jeśli wyjdziesz poza plaski świat to okazuje sie ze taka jest natura
problemu.


> Są dwie + jeden metod poprawy projektu.

Nie ma metod poprawy projektu, gdy problem nie jest przyjemnie plaski. Twoje
podejście to prosta droga do "jeśli projekt nie odpowiada rzeczywistości to
tym gorzej dla rzeczywistośc". I doesn't Work(tm).


[..]
> jest USABLE.
>
> Nastepnie kolekcja zawiera USABLE*. I moge wolac po prostu:
>
> it->use(...)
>
> NIE POTRZEBUJE SWITCH!!!
>
> Kiedy parametry są jakieś niepasujące. To znaczy jedna klasa
> wymaga int druga string.

Nie. To bardzo czesto znaczy ze jedna klasa wymaga 0 inna 1 inna 2 inna 3 a
inna listy o zmiennej dlugości. I typy tych parametrów tez są skrajnie
rózne -- po np. jeden to jakiś skalar a inny to... inny element naszej
struktury lub nawet cala jej podstruktura.

>
> Wyjście:
>
> Opakowac parametry w klase boost::any, DynamicAny, whatever.
> Moze byc boost:variant, który jest bardziej restrykcyjny niz boost::any.

Gdy róznice są tak zasadnicze jak to opisalem akapit wyzej to to wyjście
jest do bani bo tylko przesuwa problem nieco w bok komplikując i
zaciemniając kod.

It doesn't Work(tm) po raz drugi.

[...]
> Alternatywa:
>
> Jezeli jest jakieś specjalne bardzo pokrecone zachowanie.
> Rozwazam (i o tym pisalem) zastosowanie listy typów.

Lista typów statyczna ma wade o jakiej mowa w calym tym odgalezieniu. Co z
tego, ze jest statyczna skoro nie ma statycznej detekcji kompletności,
którą daje rzeczony Wizytator.
Jak nie uzywam statycznych gwarancji, sprawdzanych podczas kompiplacji, to
po co mi w ogóle statycznie typowany jezyk.

[...]
> W kazdym razie znowu nie mam switch po typach odwiedzanych.

Switch z gwarancją kompletności czy lepiej inna forma pattern-matchingu
typów (algebraicznych) jest lepsza niz Wizytator. To co proponujesz jest
zle, bo traci statyczną kontrole poprawności.

[...]
> I tu przechodze do sedna, padlo określenie:
>
> "Poniewaz wizytor to jezykowy idiom, wprowadzony po to aby
> ominąc ograniczenia np.: C++ i Javy."
>
> Wizytor to nie jest lekarstwo na braki w jezyku.
> To jest dziurawa przykrywka na śmietnik w kodzie i w projekcie.
> Dziurawa i dlatego potrzeba w switch'u:

Nonsens. Jezyk ogólnego przeznaczenia który ignoruje istotny obszar ogólnej
rzeczywistości ma powazną wade.

[...]
> "Zastanawialem
> sie czy inni grupowicze, odczuwali potrzebe takiej
> konstrukcji w C++. Ewentualnie ktoś coś moze slyszal, ze
> byly takie propozycje w przyszlej wersji standardu."
>
> Komitet, który szanuje, ma wystarczająco duzo problemów,
> aby zajmowac sie śmietnikiem w moim kodzie.

To nie jest świetnik w czymiś kodzie tylko dostostosowanie sie do
rzeczywistości która czesto nie chce byc plaska.

> Dlatego
> NIE uwazam, ze komitet ma zając sie poprawą switch'a
> tylko dlatego, ze Wizytator bedąc slabym wzorcem
> projektowym, którego trzeba latac switchem, a to wymaga poprawy
> switcha.

Co ty tu w ogóle? Wizytatora nie lata sie switchem. Wizytator to jest idiom,
obejście, na brak odpowiedniej konstrukcji jezykowej.


> To co do tej pory mialem, to nie potrzebowalem switcha
> do wizytacji. Wizytacja dla mnie nie koniecznie wiąze sie
> z uzyciem wizytora.

Maslo niemaślane?


> Przykladowo dla mnie kod:
>
> Cytuje:
>
> void bar()
> {
> // tu mam w polu widzenia x, y, z, t, u, v, itd. RÓZNYCH typów
> switch ( e.Type )
> {
> case Type.UnaryExpression:
> zrób coś z x, y i z;
> case Type.BinaryExpression:
> zrób coś z u, v;
> }
> }
>
> To jest kod do re-faktoringu.

Nonsens. UnaryExpression to nie BinaryExpression i nie ConditionalOperation
i nie FusedBinaryExpression i nie TernaryExpression i nie
FunctionApplication.

Ich uzycia nie podlegają ujednoliceniu z tego fundamentalnego powodu, ze to
na czym są uzywane jest zasadniczo inne.

[...]
> Mam ograniczone doświadczenie,

Zauwazyliśmy ;)

> ale do tej pory nie spotkalem sie
> z sytuacją, kiedy nie dalo sie tego uporządkowac, adaptery + MyParams.

To nie jest porządkowanie tylko powodowanie balaganu.

> Chodzi mi caly czas o pelną enkapsulacje.
>
> Nie zgadzam sie z określeniem "deficiencies in the language" w treści
> (patrz dalej):
[...]

Mozesz sie zgadzac lub nie -- faktów to nie zmieni.

> C++ i Java mają wady, ale czy brak kontroli switch w kontekście
> Wizytatora, do jest "deficiency"?

Tak.

> Poza tym Qrczak juz powiedzial, ze, np.
> GCC oferuje tą usluge i widac, ze nie potrzebowala ona wynikac z jezyka,
> ale jest traktowana jako ficzer kompilatora. To calkiem zmienia
> klopotliwośc tej uslugi

?????

> , co wiecej to jest realizowane przez warning.
> A standard nie rozróznia pojecia warning i error (wypowiedz Sebastiana).
> Dodatkowo ta wlaśnośc kompilatora w zgledem switch jest slaba.
> Jeśli ktoś zamiast switch w obsludze Wizytatora uzyje
> if (){} else if(){} ... to co?

To nie jest obsluga Wizytatora! Wizytatora tu nie ma!

> Jak to zostanie sprawdzone?
> Ciekawy ten wzorzec, ze mialby tylko jedyną sluszną implementacje
> poprzez uzycie switch -- to nawet wzkaLników jest kilka rodzai.

To *nie jest* implementacja Wizytatora!!!

To Wizytator jest obejściem na brak walściwej konstrukcji jezykowej.

[...]
> Podsumowując posluze sie ordynarnym stwierdzeniem.
>
> Wizytator jest jak burdel w mieście.
> A jezyk jest jak miasto, w prawie kazdym mieście
> mozna otworzyc miejsce "wątpliwej przyjemności i niewątpliwej rzezączki"
> (A. Sapkowski).
>
> Gdyby w kodzie byl porządek to wizytator nie jest potrzebny.

Gdyby problemy bylo nudno plaskie to rózne rzeczy nie bylyby potrzebne.
Wizytator jest potrzebny jako idiom w jezykach statycznych, w których brak
odpowiedniej konstrukcji.

[...bajka ciach...]

pzdr

Maciej Piechotka wrote:

> Sebastian Kaliszewski <s.usun.to> writes:
>> Jeszcze gorzej ;)
>> Moze rozwine - co jeśli A, B i C znajdują sie w bibliotece libtools.so
> (tools.dll) a D w pliku wykonywalnym app (app.exe)?
>
> a) Zabronic tego typu rzeczy, zrezygnowac z kompatybilności wstecz
> i wiekszośc kodu wrzucic do /dev/null. Oczywiście trzeba jakoś zintegrowac
> linker z kompilatorem...

Istnieją (ba istnialy 15 lat temu) kompilatory w których linker jest
mądrzejszy od tego stosowanego do C. Ba, standard tego typu ficzerów (albo
mądry linker albo inny mechanizm dający równowazny efekt -- np. generowanie
dodatkowego pliku "interfejsowego" odpowiednio rozumianego przez kompilator
i "przeplatanej kompilacji", linker moze wtedy pozostac glupi) i tak wymaga
(extern template) tylko leniwi producenci to olali.

> b) Skupic sie na warringach dla A, B i C cicho milcząc na temat D (o
> którym nie wiemy) i to w dodatku w czasie linkowania najpewniej
> (dowidzenia wszystkie dotychczasowe kompilatory i linkery)
> c) Zrobic to w linkerze i obserwowac kompilując app czy takie przypadki
> nie wystepują (wspaniale - szukanie 'bledów' w cudzej bibliotece nie na
> poziomie API/ABI)
> d) Inne?

Nie da sie zrobic .dll uzywającego cech C++ a nie tylko C, nie udostepniając
jego interfejsu w postaci Lródlowej. Tak wiec tak czy siak, nie mozesz
dostac .dll czy .so w którego interfejsie są klasy bez udostepnienia tego
interfejsu w postaci zjadliwej dla kompilatora.

Istnienie klas wewnątrz dll staje sie cześcią jego interfejsu.

Seweryn Habdank-Wojewodzki wrote:
>> W normalnych jezykach nie ma headerów.
>
> Prawdziwe jest stwierdzenie:
> Nie we wszystkich jezykach są headery.

Z nieezoterycznych są w 3: C, C++, Objective-C

>> BTW. po czym dziedziczy D?
>
> Po A albo po niczym.

Jak po niczym to D jest niezalezne od hierarchii, jeśli zaś po A, to
kompilator kompilując sobie to co zawiera D ma udostepnic samemu sobie
informacje o tym, ze D dziedziczące z A powstalo.

Albo tak jak w propozycji Macka (i jak to zrobiono w Adzie) -- w ogóle nie
ma problemu, bo nie sprawdzamy wprost klas, a wartości określanego enuma,
przy czym to juz do kodu klas (napisanego przez programiste) powiązanie
tego enuma z klasami, np:


static enum IdentyfikatoryKlas { /* ... */ };

/* static to rozszerzenie, oznacza tyle, ze wszelkie konstrukcje switch mają
sprawdzac wszystkie wartości, zamiast static moze byc np. auto */

class Bazowa
{
/* ... */
public:
virtual IdentyfikatoryKlas DajId() = 0;
};

/* w innym pliku */
class JednaZKlas: public Bazowa
{
/* ... */
public:
virtual IdentyfikatorKlas DajId() { return IdentyfikatorJednejZKlas; }
};


Przy takiej konstrukcji w ogóle nie trzeba zmieniac sposobu linkowania.
Autor klasy bazowej i enuma wymusza odpowiednie tworzenie klas pochodnych.


>
> Nie. Przyklad:
>
> class Foo;
> class Bar;
>
> typedef ::boost::shared_ptr<Foo> Foo_ptr;
> Foo_ptr foo_ptr;
>
> Nie mam problemów z kompilacją.

I co z tego? Poprawny kod ma sie skompilowac.
Ale np. to sie nie skompiluje

class Foo {};
class Bar: public Foo {};

Bar *ptr = new Foo();

Nie skompiluje sie bo jest bląd. Zadaniem systemu typów jest wykrywanie
bledów.


[...]
>> W tym Wizytatorze masz Dokladnie to Samo(tm). Tylko, ze wiecej kodu i kod
>> jest porozrzucany po róznych miejscach.
>
> To nie jest wizytator. To jest gniot na rządanie.

Nie. To jest Wizytator -- na tym on wlaśnie polega.

[...]
>> >Czyli nie wychodze
>> > przez tydzien z pracy do domu, bo Xinski napisal klase,
>> > a ja weekend mam zamknąc wersją ktora sie kompiluje.
>>
>> Komililuje ale nie dziala? Ciekawe...
>
> Nie dziala w sensie, ze nie jest uzywana (aktywnie).

Jeśli Xinski dopisal klase a ty jej nie obslugujesz to nie dziala w sensie
najbardziej parszywym -- jest bug.

>> BTW. to jest problem zarządzania wersjami. Jak jest do kitu to "Świety
>> Boze nie pomoze"...
>
> Dla mnie do kitu to jest wizytator robiony switchem.

Mniej do kitu niz Wizytator "Obiektowy" taki jak go opisuje GoF.


[...]
>> Przeczytaj jescze raz o Idiomie Wizytator ( (c) Maciek Sobczak). Tu jest
>> to samo :)
>
> Po raz czwarty? Jak ja do pracy wstane?
>
>> > Oby nie.
>>
>> Oby tak.
>
> Czy standard C++ ma sie zajmowac problemem AIDS w EU?

Standard C++ czyli jezyka ogólnego przeznaczenia ma sie zajmowac
uzytecznością tego jezyka do rozwiązywania ogólnych problemów (w tym np.
pisania translatorów jezyków)


>> "Wzorzec" Wizytator stwarza doklądnie takie same problemy!
>
> Ja sie zgadzam z Mackiem, ze Wizytator to jest bląd u samej podstawy.

Chyba nie zrozumialeś. Maciek zamiast Wizytatora proponuje co innego,
wlaśnie ów Checked Switch.


>> Oh, wzorzec wizytator jest zatem karygodny :)
>
> Tak i nie. To jest sygnal na re-faktoryzacji.

Jak juz napisalem gdzie indziej pewne problemy są wredne i albo mamy
odpowiednią konstrukcje jezykową (typy algebraiczne, checked switch) albo
robimy obejście idiomem Wizytator. Inne wyjścia charakteryzują sie
niedopuszczalnym poziomem kaszany w kodzie.

pzdr