🚀 go-pugleaf

Sektor van Skijlen wrote:

>> > Portfel nie jest typem wartościowym.
>> > 
>> > Ilość pieniędzy w portfelu jest jedynie jednym ze stanów tego obiektu,
>> > podobnie jak ilość kart kredytowych w środku, kolor portfela i
>> > materiał, z którego go wykonano.
> 
>> I w _każdym_ systemie tak to modelujesz? Z pełną otoczką? Piękny przykład
>> wzorca "swiss army knife".
> 
> Nie używaj pojęć, których znaczenia nie rozumiesz.

Nie czyń założeń, na które nie masz dowodów.

> 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. Dlatego nie ma np.
uniwersalnej implementacji portfela, która jest dobra w każdym
systemie.
Gdyby tak było, jak grzyby po deszczu powstawałyby biblioteki, które
implementują obiekty naszej codzienności.

> 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.

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?

> 
>> > 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.

> 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ć?

> 
>> >> 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?

>> > 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ć.

>> 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.

> 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".

Ty dla odmiany uważasz, że najczęściej nie. Na razie jednak nie potrafisz
udowodnić dlaczego Twoja teza jest lepsza od mojej.

> 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.

> 
>> 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. Pozwalam to ocenić innym. Również Tobie, choć przyznam, że 
nie odbieram tych ocen zbyt serio.

Daj szansę innym pochwalić Twoje umiejętności. Może kiedyś to nastąpi.

>> >> "Prawdopodobnie" to dla mnie trochę za mało. Szczególnie w przypadku
>> >> szablonów, które według mojej praktyki z reguły są po prostu
>> >> przeznaczone dla obiektów oferujących określony interfejs. I innych
>> >> ograniczeń w ich użyciu właściwie nie ma.
>> > 
>> > Tak, dokładnie. Ale typy wartościowe zwykle mają inny interfejs, niż
>> > typy obiektowe.
> 
>> Znowu ogólnik: "zwykle"... "Sprzedajesz" nam teorię, która ma działać w
>> praktyce, ułatwiać ją. Chciałbyś, żeby Twój samochód "zwykle" działał?
> 
> Oczywiście teoretycznie może istnieć taki wzorzec, który typom nie stawia
> żadnych wymagań, ale w praktyce nie spotkałem się z takim.
> 
> Wymagania co do typów zawsze określają poszczególne operacje, które na
> typie można wykonać. I te operacje świadczą też o tym, czy typ jest
> wartościowy, czy nie.
> 
> 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ę?

>> >> > 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ę.

> 
>> 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ć.

> 
> Transakcja też jest obiektem, tzw. "wartość transakcji" jest atrybutem
> obiektu transakcji, a ilość pieniędzy, na którą opiewa transakcja, jest
> wartością.

Otóż to!

> 
>> I podobnie z właścicielem. Krótko mówiąc "konto jest anonimowe" i
>> przechowuje jedynie swoje saldo (wartość) oraz numer (tożsamość).
> 
> Numer jest atrybutem obiektu (unikalnym, więc jest ściśle związany z
> tożsamością), właściciel też jest obiektem (w bazie banku jest osobnym
> obiektem, który może być podmapowany do kilku kont). Saldo jest stanem
> konta, a wartość salda to ilość pieniędzy znajdujących się na koncie.

Dlaczego "ilość" nie jest według Ciebie "wartością"?

>> Nie wiem, czy to ma sens, ale nie możesz chyba wykluczyć, że w jakimś
>> tam systemie może mieć.
> 
> Niestety nie. Przykro mi.

Cieszę się, że choć raz przyznajesz mi rację i nie próbujesz tego wykluczyć.

> 
>> > 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".

-- 
Mariusz Lotko