🚀 go-pugleaf

Dnia Thu, 15 Mar 2007 06:12:44 +0100, Mariusz Lotko skrobie:
> Sektor van Skijlen wrote:

> >> > Swiss army knife to by było, gdyby ten portfel mógł przechowywać
> >> > pieniądze, laptopy, meble, samochody, kontenery i elektrownie.
> > 
> >> Nie. Swiss army knife oznacza, że modelujesz wszystkie elementy
> >> rzeczywistości czy tego wymaga system czy nie.
> > 
> > Nie wiem, jak ty, ale ja pojęcie "swiss army knife" znam jako jeden z
> > błędów OO, który polega na stworzeniu klasy o zbyt dużym zakresie
> > odpowiedzialności.

> Ja też. Dlaczego uważasz, że modelowanie większej części rzeczywistości
> od wymaganej nie jest "zbyt dużym zakresem odpowiedzialności"?

Bo odpowiedzialność jest jedna, niezależnie od dokładności modelowania.

> > Dokładność modelowania to zupełnie inna sprawa.

> Inny będzie poziom szczegółowości klasy Samochód w kartotece
> samochodów w Urzędzie Miasta, a inny w kartotece warsztatu
> samochodowego.

To nie ma znaczenia.

> > Zresztą, jeśli dla ciebie programowanie obiektowe jest modelowaniem
> > rzeczywistości, to obawiam się, że możemy naszą dyskusję wznowić za parę
> > lat, jak będziesz już mówił językiem własnego doświadczenia, a nie
> > książkowym.

> I znowu założenia... Załóż przez chwilę, że nie jesteś jednak
> nieomylny.

Ja tylko stwierdzam fakt.

> > (Na marginesie: to bardzo dobrze, że literatura do OO twierdzi, że
> > programowanie obiektowe jest modelowaniem rzeczywistości. Tak bowiem
> > należy tą sprawę tłumaczyć początkującym. Im więcej jednak człowiek
> > programuje obiektowo, tym bardziej się przekonuje, że to nie ma nic
> > wspólnego z prawdą. To jest jeden ze znaków rozpoznawczych, czy ktoś
> > potrafi myśleć samodzielnie rzeczywiście dysponuje doświadczeniem
> > zawodowym, czy recytuje z pamięci wiedzę książkową.)

> Dla mnie odnoszenie się do rzeczywistości jest wygodną praktyką
> w takich bezsensownych dyskusjach jak ta.

Wygodną, ale niekoniecznie właściwą. Bo wiele systemów i szczegółów
definicyjnych nie posiada odniesienia w rzeczywistości. Można więc
rzeczywistość przywoływać dla porównania ("przypowieści"), ale nie do
dowodzenia.

> > Cofając jednak tą całą dygresję, którą nie wiem po co wprowadziłeś -
> > podałem ci tylko przykład, dlaczego portfel nie może być typem
> > wartościowym.
> > 
> > Jeśli nie zrozumiałeś nadal, to wytłumaczę ci bardziej łopatologicznie:
> > portfel zawierający tyle samo pieniędzy, to nie ten sam portfel (mówię
> > tak, bo twierdziłeś, że ilość pieniędzy może być wartością potrfela).

> Może być. Jeśli zastanawiałbym się "czy to ten sam portfel" to rozważałbym
> tożsamość a nie wartość portfela. Rozumiesz?

To ty nie rozumiesz.

Typ wartościowy jest typem, którego obiekt jest identyfikowany zawsze przez
wartość. Więc jeśli portfel z tą samą ilością pieniędzy nie jest tym samym
portfelem, to portfel nie jest typem wartościowym.

> >> > Ilość pieniędzy nie jest wartością portfela. Jest jego stanem. Portfel
> >> > nie może mieć wartości - i to nie dlatego, że poza tym może mieć
> >> > jeszcze wiele innych stanów i atrytbutów.

> Taki podałeś wcześniej argument. Dla mnie podział na obiekty wartościowe
> i niewartościowe jest sztuczny, żeby nie powiedzieć nieistniejący, więc
> nie dziw się, że opornie podążam za tą teorią.

To jest wyjaśnienie, nie argument. Jeśli jesteś betonowy na tą teorię, to ja
ci nic nie poradzę. Nie powiem, żeby mnie to martwiło.

> >> Wychodząc z tego założenia stanem "obiektu" "klasy" int jest np. 2. Stan
> >> ten można zmienić "funkcją" zmiany stanu, np. ++.
> >> Kto z nas nie rozróżnia wartości od stanu?
> > 
> > int x = 2;
> > int y = 2;
> > 
> > Powiedz mi teraz, czy "x jest y".

> W C++? Nie. Odsyłam do Stroustrupa jakie mechanizmy tego języka tutaj
> zadziałały, a przestaniesz zadawać takie pytania.

No i jakie twoim zdaniem mechanizmy języka tu zadziałały?

Oczywiście, że x to jest y. Dowód:

int f( int ); // dowolna funkcja deterministyczna i bezstanowa
f( x ) == f( y ) // zawsze prawdziwe

> >> >> > Typem wartościowym może być kolor. Porównanie dwóch obiektów typu
> >> >> > kolor można porównać ze sprawdzeniem, czy na dwóch kartkach papieru
> >> >> > zapisany tam kod koloru jest ten sam. Ty chcesz, żeby przed
> >> >> > odczytaniem numeru z każdej kartki najpierw sprawdzić, czy te obie
> >> >> > kartki to czasem nie jest jedna i ta sama kartka. Jaki to ma sens?
> >> > 
> >> >> Idąc Twoją logiką: niekoniecznie. Obiekt kolor ma jeszcze atrybuty:
> >> >> data naniesienia, technika wykonania i stopień nasłonecznienia, które
> >> >> pozwalają obliczyć rzeczywisty kolor w czasie :> Wtedy nie da się
> >> >> porównać dwóch "czerwonych". Odsyłam do ekspertów - lakierników
> >> >> samochodowych.
> >> > 
> >> > Nie przypominam sobie, żebym mówił o lakierze samochodowym. Mówiłem o
> >> > kolorze. Kolor może być również atrybutem (a nie wartością, acz
> >> > przypadkiem też nie stanem) lakieru.
> > 
> >> Ja tylko poszedłem Twoją logiką. Zważ, że w systemie, o którym pisałem
> >> przy portfelu nie wspominałem o istnieniu kart kredytowych.
> > 
> > Nie poszedłeś moją logiką. Mówiłem o kolorze, a ty wziąłeś sobie nie wiem
> > po co lakier samochodowy.

> Oj, lakier to już była taka wisienka na torcie.

Jasne, bagatelizuj i konfabuluj, bo żadne argumenty ci już nie zostały.

> Każdy kolor płowieje
> w rzeczywistości, a więc... (odsyłam parę akapitów wyżej).

Kolory nie płowieją. Płowieją substancje kolorujące, czyli zmieniają one
kolory.

Już widzę, z czym masz problem. Ty przede wszystkim nie wiesz, czym jest
kolor, albo czym jest liczba. Skoro tak, to nigdy nie zrozumiesz, co to
takiego typ wartościowy.

> > Podobnie typem wartościowym mogą być "pieniądze". Ale nie kieszeń,
> > portfel, konto, sejf, czy gdzie to tam jeszcze chcesz przechowywać.
> > 
> >> > No to jak, zrozumiałeś już, co to takiego jest wartość, czy douczysz
> >> > się i zgłosisz za tydzień?
> > 
> >> Do kogo miałbym się zgłosić?
> > 
> > No cóż, wydawało mi się, że każdy, kto studiował, słyszał to słynne
> > określenie. W czymś się widać pomyliłem.

> Nie mierz innych swoją miarą. Nie przypominam sobie, żeby któryś z
> wykładowców musiał się w ten sposób nade mną litować.

Zależy na jakiej uczelni studiowałeś.

> >> >> >> Z tym, że w obu przypadkach nie chodzi o "przykrą konieczność", a
> >> >> >> o "wspaniałą możliwość" szybkiego stwierdzenia, że chodzi o "te
> >> >> >> same" a więc na pewno "takie same" obiekty.
> >> >> > 
> >> >> > To jest przykra konieczność. Musisz to po prostu zrobić, bo inaczej
> >> >> > będzie wylot.
> >> > 
> >> >> W operatorze porównania? Nie sądzę...
> >> > 
> >> > W operatorze przypisania.
> > 
> >> Co miałoby sprawić "wylot" w operatorze przypisania?
> > 
> > Sprawdzenie, czy nie przypisujemy samego siebie. Fakt, że musisz użyć
> > operatora porównania dla tożsamości jest przykrą koniecznością, bo bez
> > tego usunąłbyś część obiektu, z którego za chwilę masz zamiar czytać.

> Zagadnienie pomocnicze

> int a;

> a = a;

> Pytanie: co nastąpi wcześniej odczyt czy zapis wartości a?
> Ponawiam pytanie podstawowe: jaki wylot masz na myśli?

W ogólności zależy to od definicji operatora przypisania.

W przypadku int argument przyjmowany jest przez wartość. Ale to nie musi być
reguła, nawet dla typów wartościowych. Np. std::string jest typem
wartościowym, a jego operator przypisania przyjmuje argument przez referencję.
I wtedy musisz sprawdzić.

> >> >> > Ta "wspaniała możliwość" z kolei powoduje droższe porównanie.
> >> > 
> >> >> W pewnych przypadkach może tak być.
> >> > 
> >> > Statystycznie jest to 99% przypadków.
> > 
> >> Statystycznie, to ja biję swoją żonę co miesiąc. Ty, jeśli jesteś żonaty
> >> również. Takie szacunki trzeba robić dla konkretnych klas a nie
> >> generalizować.
> > 
> > No widzisz. A ja mogę sobie pozwolić na generalizację.

> Możesz. Ale nie wpieraj, że jest ona poprawna.

Nie wpieram, tylko twierdzę.

> > Chodzi o bardzo prostą rzecz: jakiej wielkości jest zwykle typ
> > wartościowy? Niewielkiej. Musi być niewielki, bo im większy, tym więcej
> > zasobów zajmuje jego wartość, dłużej się kopiuje, a i porównanie wartości
> > - dosć częsta operacja - trwa dość długo. Dlatego właśnie typy wartościowe
> > robi się z założenia JAK NAJMNIEJSZE - właśnie po to, żeby te operacje
> > były jak najszybsze. Skoro istnieje taka presja na obiekty wartościowe, to
> > gdzie masz w takim razie pole dla obiektów, w których porównanie można
> > "przyspieszyć" poprzez najpierw sprawdzanie tożsamości?

> To jest przypadek szczególny a nie ogólny. Nie twierdzę jednak, że przypadek
> odwrotny, czyli taki jest ogólny, uniwersalny i najlepszy.

Zgadza się - bo takiego tutaj nie ma. Wszystkie przypadki tutaj są szczególne.

Ale przypadek, o którym ja wspomniałem, mimo szczególności, występuje w
przeważającej większości sytuacji, a to, co ty podałeś, jest akurat do niego
odwrotny - co w zupełności nie przeszkadza ci twierdzić, że jest przypadkiem
ogólnym.

> >> >> Implementując operator warto
> >> >> oszacować prawdopodobieństwo porównywania tych samych obiektów.
> >> > 
> >> > Zrób sobie małą statystykę użycia takiego typu i ilość porównań, dla
> >> > których trafiasz na równość i dla których trafiasz na nierówność.
> >> > 
> >> > Prosty przykład - iteratory. Masz pętlę, w której przechodzisz przez
> >> (...)
> >> > 
> >> > Podałem ci tylko przykład, jak należy prowadzić taką analizę - to, że
> >> > ten przykład jest negatywny dla twojej tezy, nie ma znaczenia. Myślę,
> >> > że dałoby się znaleźć przykład, który by twoją tezę potwierdzał, ale to
> >> > nie ma większego znaczenia.
> > 
> >> Nie będę ani analizował Twojego przykładu, ani mu zaprzeczał. Zakładam,
> >> że jest słuszny. To jednak tylko przykład, z którego do sformułowania
> >> reguły jeszcze daleko.
> > 
> > To był przykład wykonania analizy, który pokazał, że się nie opłaca. Czy
> > jesteśw stanie podać mi kontrprzykład - czyli taki, który udowodni, że się
> > opłaca?

> Proponuję przypomnieć sobie na czym polegał _dowód_, a nie przykład
> potwierdzający słuszność danego twierdzenia.

Nie przypominam sobie żadnego dowodu.

> >> > W odróżnieniu od ciebie jednak, ja rozumiem konieczność wykonania
> >> > analizy, która dowiedzie, czy to się nam opłaca, czy nie. Ty
> >> > przyjmujesz "w ciemno", że sprawdzanie najpierw tożsamości będzie
> >> > zawsze bardziej opłacalne. W ostateczności zgadzasz się nawet, że
> >> > "najczęściej".

> Jeśli przyjmowanie w ciemno to f(n), to jesteś zaledwie na etapie f(n)-1.
> Warto było się napracować?

A jesteś w stanie to udowodnić? To słucham.

> >> Ty dla odmiany uważasz, że najczęściej nie. Na razie jednak nie potrafisz
> >> udowodnić dlaczego Twoja teza jest lepsza od mojej.
> > 
> > Potrafię, tylko ty nie potrafisz jej zrozumieć, albo uparcie zaprzeczasz
> > faktom.

> Nie zaprzeczam, tylko wskazuję, że są to zaledwie pojedyncze fakty, a nie
> ogólna zależność. Nawet nie: nie zaprzeczam zależności, ale Twojemu
> sposobowi pseudodowodzenia.

To nie jest dowód, a przedstawiona teoria nie jest zależnością.

Jest to tylko stwierdzenie poprawne w statystycznej większości przypadków -
ale to nie ma znaczenia. Ty uparcie twierdzisz, że odwrotne postępowanie jest
przypadkiem ogólnym, więc w ogólności żeby twoje bzdury obalić wystarczy mi
podać jeden przykład. Fakt, że ten przykład reprezentuje większość
statystyczną nie ma tu nawet znaczenia.

> > Moja teza jest lepsza, bo jest oparta na rzetelnej analizie (nb. analiza
> > Qrczaka również). Twoja teza, że to jest "oczywiste, że tak się powinno
> > zawsze robić" nie jest poparta niczym.

> Nic takiego nie napisałem. Oczywiste jest dla mnie, że nie zawsze powinno
> się robić tak jak Ty piszesz.

Dobra, dyskusja zaczyna mi się nudzić, skoro zaczynasz zaprzeczać swoim
niedawnym stanowczym wypowiedziom (równie stanowczo zresztą).

> >> > No to podaj mi przykład typu wartościowego, w którym to się opłaca, i
> >> > oszacuj ilość porównań trafionych i nietrafionych w typowych
> >> > algorytmach, które go używają. Wtedy będziemy wiedzieli, o czym
> >> > rozmawiamy.
> > 
> >> Nie chodzi o sam typ, tylko kontekst użycia.
> > 
> > Brawo! Zatem słucham.

> Użycie typu jako klucza w hash mapie.

No fajnie - czyli, jak rozumiem, masz taki klucz, którego porównanie z
istniejącym zaczynasz od sprawdzenia tożsamości klucza? No dobrze. Jak zatem
wygląda definicja typu klucza?

> >> >> Generalnie jednak - nie zgadzam się.
> >> > 
> >> > Ależ masz pełne prawo się nie zgadzać. Ja w odróżnieniu od ciebie
> >> > potrafię to uzasadnić.
> > 
> >> W odróżnieniu od Ciebie unikam jednoznacznych stwierdzeń na temat swoich
> >> umiejętności.
> > 
> > Z tą "oczywistością", że operator porównania powinien najpierw sprawdzić
> > tożsamość, niespecjalnie ci to wyszło.

> W większości przypadków, jeśli analiza wykaże, że się opłaca. Nie przekręcaj
> moich słów.

O analizie to dopiero ja zacząłem mówić, więc nie wmawiaj, że cokolwiek
takiego twierdziłeś.

Jestem i tak za leniwy, żeby zajrzeć do wcześniejszych wiadomości i
skompromitować cię twoimi wcześniejszymi wypowiedziami.

Poza tym, podoba mi się to: w większości przypadków, jeśli analiza wykaże, że
się opłaca. Super. Analiza może wykazać, że w 90% przypadków się nie opłaca,
ale to i tak te 10% to będzie dla ciebie większość.

> >> > Przykładowo, typ przechowywany w std::list musi być typem wartościowym.
> >> > Niestety, tak jest skonstruowany szablon std::list. Świadczą o tym
> >> > następujące wymagania względem typu:
> >> >  - przypisywalny
> >> >  - kopiowalny
> >> >  - domyślnie-konstruowalny
> > 
> >> Rozumiem, że jeśli stworzę sobie jakiś widget, powiedzmy combo-box, który
> >> spełnia powyższe wymagania, to nie będę mógł, go przechowywać w
> >> std::list, bo pogwałcę Twoją teorię?
> > 
> > Nie. Bo jak wykonasz na nim algorytm std::remove, to zdrowo się zdziwisz,
> > co po tym powstało.

> Nie pisałem nic o chęci użycia któregokolwiek z algorytmów.

Dobrze, zrób sobie cokolwiek - nawet sortowanie (sortowanie listy jest
algorytmem wewnętrznym listy, a nie ogólnym), scalanie z inną listą, czy
cokolwiek innego.

Pomijając już fakt, jak zamierzasz określić "kopiowalność" widżetu, oraz jak
zamierzasz określić jego porównywalność (potrzebną do find) i porządkowalność
(potrzebną do sort).

W różnych przypadkach, przy różnych operacjach, funkcje operujące na liście
potrafią ci skopiować określony obiekt, przechować kopię w obiekcie
tymczasowym i wrzucić do listy, a stary usunąć - tak właśnie działa np.
sortowanie, czy odwracanie (w szczególności wszystkie algorytmy zmieniające, w
tym również algorytmy zaimplementowane jako metody listy).

> >> >> >> > Jeśli mówimy już o rzeczywistości - podaj mi przykład obiektu z
> >> >> >> > rzeczywistości, który posiada jednocześnie wartość i tożsamość.
> >> >> > 
> >> >> >> Konto bankowe. Tożsamość: numer, wartość: saldo.
> >> >> > 
> >> >> > Oraz wartość: właściciel (można go potem kiedyś zmienić)
> >> >> > Oraz obiekt: historia transakcji
> >> >> > Oraz...
> >> > 
> >> >> Jak wyżej: zależy od kontekstu.
> >> > 
> >> > Nic nie zależy od żadnego kontekstu.
> >> > 
> >> > Saldo jest stanem (cząstkowym) konta. Saldo jest wartością. Konto jest
> >> > obiektem.
> > 
> >> Niepotrzebnie wiążesz terminy z życia (stan konta) z terminami
> >> informatycznymi (stan obiektu). Osobom z małym doświadczeniem to się
> >> często zdarza, nie przejmuj się.
> > 
> > Parafrazując, "Skończył się czas argumentów. Teraz jest czas inwektyw".

> Trafiłem widzę na wrażliwca.

A ja, jak widzę, trafiłem na kogoś zakompleksionego, kto musi się
dowartościować przez pomiatanie innymi.

> > A może tak coś do tematu?

Czyli, jak rozumiem, nie masz nic do powiedzenia "do tematu"?

> >> >> Możemy nie wiązać obiektów transakcji do
> >> >> konta, a zrobić wiązanie odwrotne: każda transakcja ma referencję do
> >> >> konta.
> >> > 
> >> > Ale co to ma do rzeczy?
> > 
> >> To, że obiekt konto nie musi przechowywać historii, jeśli tylko zechcę
> >> tak to zamodelować.
> > 
> > No może, i nadal, co z tego?

> Guzik. Polecam lecytynkę, bo nie pamiętasz już co napisałeś kilka postów
> temu i dlaczego staram się uwalić pomysł, że konto _musi_ przechowywać to
> tamto i sramto.

No ok. I nadal, co z tego?

Czy chcesz może dojść do tego, żeby konto nie przechowywało niczego, co nie
jest niezbędne, żeby mogło być typem wartościowym? Już ci powiedziałem: konto
nie będzie nigdy typem wartościowym, żebyś się nawet zesrał.

> >> >> > Czy ty w ogóle wiesz, co to jest "wartość"?
> >> > 
> >> >> Element ze zbioru (tu: typ, klasa).
> >> > 
> >> > To znaczy?
> > 
> >> Odsyłam do książki "Matematyka dla klas drugich".
> > 
> > Cóż, osobliwy masz wybór literatury do nauki programowania, ale to już nie
> > moja sprawa.

> Widzę, że pozycja, o której wspomniałem jest Ci obca. W przeciwnym razie
> wiedziałbyś, że nie ma tam słowa o programowaniu.

Jest mi, owszem, obca. Kiedy ja chodziłem do "klasy drugiej", ta pozycja
nazywała się inaczej.


Mógłbym się jeszcze trochę na tobie powyżywać, bo póki co rozmowa z tobą nadal
mnie bawi, ale spróbujmy wrócić do tematu - im bliżej tematu tym zawsze się
bardziej kompromitujesz.

No więc, co to takiego jest "wartość"?


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"