🚀 go-pugleaf

Odpowiadajac na list Rafal Posmyka

> [w tm miejscu znadowalo sie rozwiazanie Rafala problemu]
> [zapisu obiektow w RBD]
>
> Spodziewam sie, ze uznasz to za przerarzajaco 
> nieeleganckie :-) ...

Tak jest to nieeleganckie. Nie jest to jednak ocena Twojego
rozwiazania. Po prostu nie da sie tego zrobic lepiej.
Z tym, ze rozwiazanie jest nieeleganckie moglbym jednak 
zyc, gorsze jest to, ze jest niesamowicie czasochlonne. Zwroc
uwage, ze nasz przyklad byl prosciutki, a mimo to rozwiazanie
wcale proste nie jest. Co sie dzieje w przypadku, gdy nasz
projekt zamiast trzech klas posiada ich 100, a zaleznosci
pomiedzy nimi sa o wiele bardziej skomplikowane niz w naszym
zadaniu? To bylo pytanie, retoryczne. Mysle, ze kazdy kto
przezyl to choc raz, zna odpowiedz. 

> ...Ma to jednak sporo zalet, np. mieszanie w obrebie 
> jednego duzego systemu elementow relacyjnach i 
> objektowych...

Nazywasz to zaleta? Dla mnie to zlo konieczne.

> ...Albo mozliwosc tworzenia aplikacji (frontend) 
> nieobjektowych. 

Tego nie zrozumialem

> Jest to o wiele prostsze niz laczenie danych z baz nativ
> objekzowych i relacyjnych. Czy mi wierzysz czy nie - takie
> praktyki stosuje sie na codzien, nie jest to calkowicie
> moj pomysl :-)

Wierze Ci. Sam przezylem to kilkakrotnie. Nie kazda jednak
praktyka zasluguje na nasladownie. Tej, o ktorej piszesz, nie
polecalbym w szczegolosci.

> > Rownie dobrze moglbym powiedziec, ze VisualBasic jest 
> > bardzo obiektowy biorac "pod uwage jakosc windowsowkiego 
> > API" (VB to tez przeciez programowanie w Windows).
> 
> Nie znam dobrze czystego VB, raczej "VB for apllikation"
> ale w swietle mojej poprzedniej tezy. mozna by cos takiego
> powiedziec. Moze troche dokladniej (takze w stosunku do
> OWL i MFC): "objektowy interfejs do Windows API".

Tutaj przebiles nawet Microsoft. Nawet oni nie probuja mowic,
ze VB jest obiektowy.

> > Chodzi mi o to, ze uzywajac obiektowej biblioteki do 
> > programowania w Windows chcialbym zapomniec o tym, 
> > ze cos takiego jak Windows API wogole istnieje. Czy 
> > uzywajac MFC udalo ci sie to kiedykolwiek? ...
> 
> Moj drogi nie zapominaj, ze MFC i OWL sa bibliotekami do
> GUI !!! A gdzie reszta systemu, gdzie operacje na zbiorach,
> gdzie I/O, gdzie siec, ... 

Zle mnie zrozumiales. Jesli pisze, ze dzieki bibliotece 
chcialbym zapomniec o API, to oczywiscie chodzi mi o zakres 
zadan, ktorym sie dana biblioteka zajmuje. Jesli np. 
obiektowa biblioteka X zajmuje sie OLE to uzywajac jej 
chcialbym zapomniec o OLE API. Poza tym nieprawda jest, ze
MFC i OWL to tylko GUI.

> Windows narzuca pewien styl programowania, a Delphi tylko
> go przejmuje. Tak wiec krytyka tyczyc sie powinna Windows,
> co do stylu i Delphi co do nowatorstwa (a nie stylu).

Jescze raz sie z Toba niezgodze. Podam ci przyklad: wyobraz
sobie, ze nasz program ma wyslwietlac okienko z 3 przyciskami 
w srodku (zakladam, ze takie klasy jak Okienko i Przycisk
mamy juz zdefiniowane) Mozna to zrobic na nieskonczona ilosc 
sposobow np.

1. Utworzyc 4 klasy (1 dla okienka, 3 dla przyciskow)
2. Utworzyc 1 klase (worek)
3. Utworzyc 99 klas (jesli mam taki kaprys)

Moj oryginaly przyklad z TTabbedNotebook, od ktorego watek
"Delphi i OO" sie rozpoczal (i do ktorego posrednio sie 
odwolujesz), byl troche bardziej skomplikowany, ale idea byla 
dokladnie taka sama - Delphi zawsze wybierze sposob numer 2
(co niestety nie zawsze jest najszczesliwsze)

Czy w swietle powyzszego przykladu, nadal uwazasz, ze Windows 
w jakikolwiek sposob narzuca sposob podzialu mojego programu
na klasy? Jesli nadal tak, to chetnie zobacze przyklad.

I to by bylo na tyle


Robert