🚀 go-pugleaf

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> Tak na moje, z tego co tu piszecie, to najlepsze byłoby chyba
> zdefiniowanie amfibii jako zupełnie osobnej klasy, która implementuje
> niektóre metody klas samochodu, łodzi, czołgu i do czego tam jeszcze
> jest podobna.  Co o tym sądzą Szanowni Współdyskutanci?

Sadze, ze najpierw nalezy zrozumiec czym sie rozni "klasa" od "typu".
Dlaczego klasy sie "dziedziczy", a typy sie "podtypia" (proponuje poszukac
na subtyping vs. inheritance).

Rozwiazanie okaze sie nadzwyczaj proste.


mp

Dnia Tue, 15 Nov 2005 13:22:31 +0100, Piotr Dembiński skrobie:

> Tak na moje, z tego co tu piszecie, to najlepsze byłoby chyba
> zdefiniowanie amfibii jako zupełnie osobnej klasy, która implementuje
> niektóre metody klas samochodu, łodzi, czołgu i do czego tam jeszcze
> jest podobna.  Co o tym sądzą Szanowni Współdyskutanci?

Ja osobiście już się w tej kwestii wypowiedziałem: amfibia ma implementować
funkcjonalność samochodu i łodzi. Funkcjonalność od strony użytkownika, czyli
możliwość poruszania się w określonym środowisku. To chyba mniej więcej to, o
czym mówisz.

Jakie - to można poczytać na Wikipedii, szczególnie angielskiej i niemieckiej,
bardzo ciekawe materiały ;)

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"Michal Przybylek" <mrp@neostrada.pl> writes:

> "Piotr Dembiński" <pdemb@gazeta.pl> wrote:
>
>> Tak na moje, z tego co tu piszecie, to najlepsze byłoby chyba
>> zdefiniowanie amfibii jako zupełnie osobnej klasy, która
>> implementuje niektóre metody klas samochodu, łodzi, czołgu 
>> i do czego tam jeszcze jest podobna.  Co o tym sądzą Szanowni
>> Współdyskutanci?
>
> Sadze, ze najpierw nalezy zrozumiec czym sie rozni "klasa" od
> "typu".  Dlaczego klasy sie "dziedziczy", a typy sie "podtypia"
> (proponuje poszukac na subtyping vs. inheritance).

OK, czyli tworzenie podtypu jest specjalnym przypadkiem tworzenia
podklasy -- takim, w którym tworzona podklasa jest podstawna w sensie
zasady Liskowej w miejsce swojej nadklasy.  Aye?

> Rozwiazanie okaze sie nadzwyczaj proste.

Rozwiązanie problemu amfibii czy rozwiązanie problemu refaktoryzacji
programów napisanych w języku Python?

-- 
http://www.piotr.dembiński.prv.pl

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> > Sadze, ze najpierw nalezy zrozumiec czym sie rozni "klasa" od
> > "typu".  Dlaczego klasy sie "dziedziczy", a typy sie "podtypia"
> > (proponuje poszukac na subtyping vs. inheritance).
>
> OK, czyli tworzenie podtypu jest specjalnym przypadkiem tworzenia
> podklasy -- takim, w którym tworzona podklasa jest podstawna w sensie
> zasady Liskowej w miejsce swojej nadklasy.  Aye?

Nie. Pojecia podklasy i podtypu sa do siebie ortogonalne.


mp

Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> Dnia Tue, 15 Nov 2005 13:22:31 +0100, Piotr Dembiński skrobie:
>
>> Tak na moje, z tego co tu piszecie, to najlepsze byłoby chyba
>> zdefiniowanie amfibii jako zupełnie osobnej klasy, która
>> implementuje niektóre metody klas samochodu, łodzi, czołgu 
>> i do czego tam jeszcze jest podobna.  Co o tym sądzą Szanowni
>> Współdyskutanci?
>
> Ja osobiście już się w tej kwestii wypowiedziałem: amfibia 
> ma implementować funkcjonalność samochodu i łodzi. Funkcjonalność 
> od strony użytkownika, czyli możliwość poruszania się w określonym
> środowisku. To chyba mniej więcej to, o czym mówisz.

Z tego, co rozumiem typowanie kaczkowe (lub 'uchylne'), to ogólna
metafora wygląda tak, że dostajemy obiekt i go odpytujemy: 'czy
potrafi pływać', 'czy potrafi strzelać' lub 'czy potrafi jeździć'. 
W każdym razie nie obchodzi nas, czy używany obiekt jest samochodem, 
łodzią czy BWP.

W Pythonie można jeszcze programować na zasadzie 'OK, to wjeżdżamy 
do wody' -- i wtedy obiekt albo wjeżdża do wody albo krzyczy, 
że nie potrafi :)

-- 
http://www.piotr.dembiński.prv.pl

"Michal Przybylek" <mrp@neostrada.pl> writes:

[...]

> Pojecia podklasy i podtypu sa do siebie ortogonalne.

Od kiedy?

Dnia Tue, 15 Nov 2005 16:49:58 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> > Dnia Tue, 15 Nov 2005 13:22:31 +0100, Piotr Dembiński skrobie:
> >
> >> Tak na moje, z tego co tu piszecie, to najlepsze byłoby chyba
> >> zdefiniowanie amfibii jako zupełnie osobnej klasy, która
> >> implementuje niektóre metody klas samochodu, łodzi, czołgu 
> >> i do czego tam jeszcze jest podobna.  Co o tym sądzą Szanowni
> >> Współdyskutanci?
> >
> > Ja osobiście już się w tej kwestii wypowiedziałem: amfibia 
> > ma implementować funkcjonalność samochodu i łodzi. Funkcjonalność 
> > od strony użytkownika, czyli możliwość poruszania się w określonym
> > środowisku. To chyba mniej więcej to, o czym mówisz.

> Z tego, co rozumiem typowanie kaczkowe (lub 'uchylne'), to ogólna
> metafora wygląda tak, że dostajemy obiekt i go odpytujemy: 'czy
> potrafi pływać', 'czy potrafi strzelać' lub 'czy potrafi jeździć'. 
> W każdym razie nie obchodzi nas, czy używany obiekt jest samochodem, 
> łodzią czy BWP.

> W Pythonie można jeszcze programować na zasadzie 'OK, to wjeżdżamy 
> do wody' -- i wtedy obiekt albo wjeżdża do wody albo krzyczy, 
> że nie potrafi :)

Z tego co wiem, to jest powszechnie stosowana metoda w językach dynamicznie
typowanych.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"Piotr Dembiñski" <pdemb@gazeta.pl> wrote:

> > Pojecia podklasy i podtypu sa do siebie ortogonalne.
>
> Od kiedy?

Od zawsze. Problem polega na tym, ze:

a) niektore jezyki zwiazuja owe pojecia ze soba,

b) rozni ludzie uzywaja tych terminow do okreslenia roznych rzeczy - w
szczegolnosci historyczne pojecie klasy (uzywane od tysiecy lat w naukach
filozoficznych), odpowiada dzisiejszemu pojeciu typu z terminologi
informatycznej.


mp

"Michal Przybylek" <mrp@neostrada.pl> writes:

> "Piotr Dembiñski" <pdemb@gazeta.pl> wrote:
>
>> > Pojecia podklasy i podtypu sa do siebie ortogonalne.
>>
>> Od kiedy?
>
> Od zawsze. Problem polega na tym, ze:
>
> a) niektore jezyki zwiazuja owe pojecia ze soba,

Właśnie, w kontekście p.c.objects utożsamianie typu z klasą jest 
chyba zasadne?

Pewne rozróżnienie rzeczywiście wprowadza LSP, którą ja osobiście
rozumiem jako uzupełnienie terminologii stosowanej w metodyce OO: 
można mówić o tym, że zdefiniowano podtyp mając na myśli, że
zdefiniowano podklasę zgodną ze swoją nadklasą w sensie LSP.

> b) rozni ludzie uzywaja tych terminow do okreslenia roznych rzeczy -
> w szczegolnosci historyczne pojecie klasy (uzywane od tysiecy lat 
> w naukach filozoficznych), odpowiada dzisiejszemu pojeciu typu 
> z terminologi informatycznej.

W samej informatyce pojęcie 'klasa' jest rozumiane różnie w różnych
poddziedzinach.

-- 
http://www.piotr.dembiński.prv.pl

Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

[...]

>> W Pythonie można jeszcze programować na zasadzie 'OK, to wjeżdżamy 
>> do wody' -- i wtedy obiekt albo wjeżdża do wody albo krzyczy, 
>> że nie potrafi :)
>
> Z tego co wiem, to jest powszechnie stosowana metoda w językach
> dynamicznie typowanych.

Nie tyle chodzi o język, co o sposób programowania.  W języku 
z dynamicznym systemem typów można pisać programy w stylu: 
'jeśli obsługuje, to uruchom' albo 'uruchom, a jak nie obsługuje, 
to obsłuż wyjątek'.

-- 
http://www.piotr.dembiński.prv.pl

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> > a) niektore jezyki zwiazuja owe pojecia ze soba,
>
> Właśnie, w kontekście p.c.objects utożsamianie typu z klasą jest
> chyba zasadne?

Nie. BTW: ja caly czas mowie o typach i klasach w kontekscie teorii
obiektowej (modulo to, ze cos takiego nie istnieje :-) ).

Mozna model obiektowy zaczynac od samych obiektow, a nie od klas jak to sie
robi w tradycyjnych jezykach. Wtedy czesto okazuje sie, ze klas w sensie
C++, czy Smalltalk'u w ogole miec nie chcemy (wprowadza sie inne mechanizmy,
ktore w pewnym sensie rozkladaja pojecie klasy na drobniejsze czesci).

Takie podejscie jest koncepcyjnie duzo czystsze niz podejscie oparte na
klasach.

W koncu - istnieja takze jezyki, ktore scisle odseparowuja pojecie klasy od
typu. Moze sie nawet zdarzyc, ze A bedzie podklasa B, a typ odpowiadajacy A
bedzie nadtypem typu odpowiadajacego B.


Poczytaj ksiazke, ktora Ci ostatnio polecilem. Nie cala, wystarcza rozdzialy
do wprowadzenia rachunku sigma. I zdaj nam wtedy relacje - czego sie
nauczyles  i co w Twoim wczesniejszym wyobrazeniu bylo zle.


mp

"Michal Przybylek" <mrp@neostrada.pl> writes:

> "Piotr Dembiński" <pdemb@gazeta.pl> wrote:
>
>> > a) niektore jezyki zwiazuja owe pojecia ze soba,
>>
>> Właśnie, w kontekście p.c.objects utożsamianie typu z klasą jest
>> chyba zasadne?
>
> Nie. BTW: ja caly czas mowie o typach i klasach w kontekscie teorii
> obiektowej (modulo to, ze cos takiego nie istnieje :-) ).

W CPythonie 1.5.2 każdy obiekt ma swój typ, który jest stały, tzn.
nie zmienia się przez cały czas życia obiektu.  Dodatkowo, obiekty
niektórych typów ('instance', 'class') uczestniczą w całej tej hecy 
z dziedziczeniem, polimorfizmem itepe.  Z punktu widzenia programisty
wygląda to mniej więcej tak, jakby obiekty większości typów
wbudowanych były 'final' i niemodyfikowalne.

> Mozna model obiektowy zaczynac od samych obiektow, a nie od klas jak
> to sie robi w tradycyjnych jezykach. Wtedy czesto okazuje sie, 
> ze klas w sensie C++, czy Smalltalk'u w ogole miec nie chcemy
> (wprowadza sie inne mechanizmy, ktore w pewnym sensie rozkladaja
> pojecie klasy na drobniejsze czesci).

Są języki, w których klasa jest obiektem i takie, w których klasa 
nie jest obiektem.  Podobnie z typami.  W Pythonie 1.5.2 zarówno 
klasa obiektu, jak i jego typ są obiektami.

> Takie podejscie jest koncepcyjnie duzo czystsze niz podejscie 
> oparte na klasach.
>
> W koncu - istnieja takze jezyki, ktore scisle odseparowuja pojecie
> klasy od typu. Moze sie nawet zdarzyc, ze A bedzie podklasa B, a typ
> odpowiadajacy A bedzie nadtypem typu odpowiadajacego B.

Tak, ale to jest związane z konkretnymi językami.  Mnie chodziło
właśnie o tę ogólną teorię obiektowości.

> Poczytaj ksiazke, ktora Ci ostatnio polecilem. Nie cala, wystarcza
> rozdzialy do wprowadzenia rachunku sigma. I zdaj nam wtedy relacje -
> czego sie nauczyles i co w Twoim wczesniejszym wyobrazeniu bylo zle.

Niestety nie mam do tej książki dostępu.


-- 
http://www.piotr.dembiński.prv.pl

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> > Mozna model obiektowy zaczynac od samych obiektow, a nie
> > od klas jak to sie robi w tradycyjnych jezykach. Wtedy czesto
> > okazuje sie, ze klas w sensie C++, czy Smalltalk'u w ogole miec
> > nie chcemy (wprowadza sie inne mechanizmy, ktore w pewnym
> > sensie rozkladaja pojecie klasy na drobniejsze czesci).
>
> Są języki, w których klasa jest obiektem i takie, w których klasa
> nie jest obiektem.  Podobnie z typami.  W Pythonie 1.5.2 zarówno
> klasa obiektu, jak i jego typ są obiektami.

Rany, nie opowiadaj mi o badziewiastym Pythonie...

Ja mowie o _zupelnie_ innych modelach obiektowych. Patrz np. Self, Emerald,
Cecil, Sather, model "soft objects" z dialektow Lisp'u, czy nawet CORBIT, do
ktorego link podawalem kilka tygodni temu...

Pogadaj z Qrczakiem, on wlasnie tworzy najlepszy na swiecie jezyk
programowania :-) Jego model obiektowy jest takze znaczaco inny od tych,
ktore znasz (odpowiednikiem klas sa aproksymacje czegos co sie nazywa
"features", typy zyja rownolegle).


MRP

"Michal Przybylek" <mrp@neostrada.pl> writes:

[...]

> Ja mowie o _zupelnie_ innych modelach obiektowych.  Patrz np. Self,
> Emerald, Cecil, Sather, model "soft objects" z dialektow Lisp'u, czy
> nawet CORBIT, do ktorego link podawalem kilka tygodni temu...

Nie nadążam za tokiem rozumowania.

"Michal Przybylek" <mrp@neostrada.pl> writes:

> "Piotr Dembiński" <pdemb@gazeta.pl> wrote:
>
>> > Mozna model obiektowy zaczynac od samych obiektow, a nie od klas
>> > jak to sie robi w tradycyjnych jezykach. Wtedy czesto okazuje
>> > sie, ze klas w sensie C++, czy Smalltalk'u w ogole miec nie
>> > chcemy (wprowadza sie inne mechanizmy, ktore w pewnym sensie
>> > rozkladaja pojecie klasy na drobniejsze czesci).
>>
>> Są języki, w których klasa jest obiektem i takie, w których klasa
>> nie jest obiektem.  Podobnie z typami.  W Pythonie 1.5.2 zarówno
>> klasa obiektu, jak i jego typ są obiektami.
>
> Rany, nie opowiadaj mi o badziewiastym Pythonie...
>
> Ja mowie o _zupelnie_ innych modelach obiektowych. Patrz np. Self,
> Emerald, Cecil, Sather, model "soft objects" z dialektow Lisp'u, czy
> nawet CORBIT, do ktorego link podawalem kilka tygodni temu...

No tak -- są jeszcze wspierające obiektowość języki, w których nie
istnieje pojęcie klasy.  Zresztą -- w Turbo Pascalu też nie było klas,
tylko typ obiekt i jego realizacje.

> Pogadaj z Qrczakiem, on wlasnie tworzy najlepszy na swiecie jezyk
> programowania :-) Jego model obiektowy jest takze znaczaco inny 
> od tych, ktore znasz (odpowiednikiem klas sa aproksymacje czegos 
> co sie nazywa "features", typy zyja rownolegle).

OK, czyli typy są ortogonalne do klas.  Gdzie w takim razie
umieściłbyś nieujemną liczbę całkowitą z zakresu [0..99] ze
zdefiniowaną operacją dodania modulo 100 innej nieujemnej liczby
całkowitej z zakresu [0..99]?  Tzn. jaką byś jej przydzielił klasę 
i jaki typ?  Abstrahując od języka programowania oczywiście.

-- 
http://www.piotr.dembiński.prv.pl

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> OK, czyli typy są ortogonalne do klas.

Tak.

> Gdzie w takim razie
> umieściłbyś nieujemną liczbę całkowitą z zakresu [0..99] ze
> zdefiniowaną operacją dodania modulo 100 innej nieujemnej liczby
> całkowitej z zakresu [0..99]?  Tzn. jaką byś jej przydzielił klasę
> i jaki typ?

Klasa koncepcyjnie nie ma znaczenia.

Typ sam okresliles wyzej :-) Czyli:

Powiedzial bym, ze istnieje typ int_mod_99 o elementach bedacych liczbami
calkowitymi nieujemnymi z zakresu [0..99], na ktorych zdefiniowana jest
operacja dodawania modulo 100 (oczywiscie operacja dodawania modulo 100 nie
jest tym samym co operacja dodawania). Z samej definicji widac, ze
int_mod_99 \subtype int.

Albo:

Powiedzial bym, ze elementy [0..99] moga wystepowac _w roli_ grupy z
dzialaniem dodawania modulo 100.


mp