W dniu czwartek, 20 lutego 2014 04:30:11 UTC+1 użytkownik A. L. napisał:
> On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
> wrote:
>
> >(A i tak zawsze bedzie mniej elastyczny niz wowczas,
> >gdy po prostu udostepni sie dobrze napisany kod zrodlowy
> >-- bo jego elastycznosc bedzie tylko tak duza, na ile
> >pozwolila wyobraznia jego tworcow)
>
> Szczegolnie dobrze sie ten postulat realizuje gdy w grupie jest 20
> programistow a system ma 5 milionow linii kodu

*Szczegolnie* dobrze sie ten postulat realizuje, gdy w grupie jest 1100+
programistow, a system ma 15 milionow linii kodu

http://news.cnet.com/8301-1035_3-57603216-94/linux-d
evelopment-by-the-numbers-big-and-getting-bigger/

do góry

W dniu czwartek, 20 lutego 2014 04:19:30 UTC+1 użytkownik A. L. napisał:
> On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
> wrote:
>
> Zarowno hermetyzacja jai i polimorfizm nic nie maja ze soba wspolnego
> ani nic nie maja wspolnego z obiektowoscia.

Przepraszam, ze sie powolam na to zrodlo, ale wydaje mi sie, ze
ono dosc dobrze reprezentuje "powszechne mniemanie" (i ma te zalete,
ze jezeli uwazasz, ze jest pelne glupot, a Ty wiesz lepiej, to
mozesz samemu to poprawic):
http://en.wikipedia.org/wiki/Object-oriented_program
ming,
tamze:

An object is an abstract data type with the addition
of polymorphism and inheritance.

i dalej:

Object orientation eases maintenance by the use of
encapsulation and information hiding.

> Polimorfizm mowi z grubsza o operacjach ktore moba byc zaaplikowane do
> zmiennych roznych typow, przy czym wlasciwa implementacja wybierana
> jest automatycznie, stosownie do tych typow.
[...]
>
> Polimorfizm nic nie mowi o "zastepowaniu klas".

Moze tutaj rzeczywiscie wyrazilem sie dosc niefortunnie.
Chodzilo mi o zastapienie obiektu jednej klasy obiektem
innej, implementujacej ten sam interfejs. Byl to skrot
myslowy, ale przyznam, ze nie widze jak inaczej mozna by
go sensownie interpretowac.

> Tak na marginesie, interfejs nei okrecla calkowicie zachowanai modulu;
> moduly o identycznych interfejsach nie musza byc identyczne

To chyba dosc oczywiste?

do góry

W dniu środa, 19 lutego 2014 20:20:36 UTC+1 użytkownik A. L. napisał:

> rzeczywiscie, powstrzymam sie od komentowania. Zzajeloby mi zbyt duzo
> czasu ktorego nei mam.
>
> Proponuje wyjsc poza SICP i poczytac wiecej. N poczatek Clemensa
> Szyperskiego, na przykald
>
> http://research.microsoft.com/en-us/um/people/cszype
rs/pub/ecoop92.pdf

Produkowanie cyfrowej makulatura wydaje sie rzeczywiscie ciekawym
zjawiskiem, jednak trudno mi pojac, jak odnosi sie to do
poruszanego wczesniej tematu.

> SICP jest dsyc zlezala i trudnia ja dzis traktwoac jako solidne
> zrodlo.

Ma Pan oczywiscie prawo do wlasnej opinii. Jest to jednak
najlepsza ksiazka dotyczaca programowania, z jaka mialem
kiedykolwiek stycznosc -- a dzieki temu, ze ujmuje zjawisko
programowania w ogolnosci, trudno mi sobie wyobrazic, zeby
mogla sie kiedykolwiek zdezaktualizowac.

> Zreszta, fragmenty ktore Pan cytowal niespecjalnie maja sie do
> tego co Pan napisal.

Byla to najlepsza odpowiedz, jakiej moglem udzielic na zadane
przez Pana pytanie, ktore brzmialo, przypomne, "Ze co?..".

Gdyby pytanie bylo postawione bardziej precyzyjnie, to moze
moglbym udzielic pelniejszej odpowiedzi.

do góry

dla mnie tez dziedziczenie/polimorfizm [co ja sam wolalbym nazwaz programowaniem na
ogolnikach - tj takie programowanie gdzie zastepujesz konkretny typ pewna klasa
typów] jest innym paradygmatem niz czyste oo - zobacz np ten przyklad podany przez
uzytkownika toslaw, wlasnie wycialem stamtad elementy dziedziczenia po to zeby
uproscic sprawe a nadal jest to przyklad na oop

sam bardzo rozbudowalem i niejako zunifikowałem system modułowy (napisałem o tym pare
postów),
dodalem m.in. mozliwosc instancjonowania modułow
i jesli wybrac sposród tego niektóre charakterystyczne elementy to mozna powiedziec
ze niektore (te lepsze) elementy oop 'wtopiły sie' w to [w tym ze bylbym badzo
obrazony gdyby mowic ze
cos tu zostalo przejete od oop, bo dla mnie oop
(taki jaki znam z javy albo c++) to niesamowita chała której szczerze niecierpie,
raczej po prostu
pewne czesci mojego systemu (który jest 'generalny')
pozwalaja wyrazić lepiej to co w oop jest umieszczone w kontekscie pewnego koszmaru)

specjalny opopodobny przykład z mojego systemu modułowego*

main()
{
Int x;
Int y;
Int z;

x.add(y);
y.add(z);
z.add(x);

Monitor m1, m2, m3;

x.add(m1);
x.add(m2);
x.add(m3);

x.run();

}

Int jest tutaj modułem który jest instancjonowany
3 razy do encji x y z

przez te linijki z add zakladam pewien taki łancuch
kółeczko encji x->y->z->(x->) (w opopodobny sposób
tj przez fizyczny wskaznik) tak by np dzialalo to jak trzy fabryki x produkuje cos i
uruchamia y ktore
produkuje cos i uruchamia z ktore wtedy produkuje cos i uruchamia z
na przyklad

x produkuje "1111" (**mozna w x napisac parolinijkowa funkcje ktora to bedzie
robic:)

y produkuje z tego "2222"
z produkuje z tego "3333"
x produkuje z tego "4444"

do x y i z podpiałem trzy encja monitora tak ze na
monitor jeden bedzie szedł napis "1111" "4444" "7777" na drugi "2222" "5555" itd


[* specjalnie zostawilem to oznaczenie z kropka zeby wykazac podobieństwo
gdy normalnie w moim systemi emodulowym bardziej
naturalne sa wywolania "x add(y)" dla zwykłych funkcji (ew "x add y" dla operatorów)]

[**

Int.c:

module Int uses Monitor&

unsigned data[4];

Int& consumer;
Monitor& monitor;

void produce()
{
data[0]++;
data[1]++;
data[2]++;
data[3]++;
}

external void add(Int consumer){
consumer& = &consumer;
}

external void add(Monitor m){
monitor& = &monitor;
}

external void run()
{
produce();
monitor& show();
consumer& run();
}

Monitor.c (skip)

specjalnie wypichcony obiektowopodobny kawałek
tj komunikacja za pomoca fizycznych referencji
(w nieco przypadkowej składni), sa tu ze
cztery czy piec ciekawych tematow m.in
ciekawe dla mnie jest to ze jak sie raz "sklei"
Inta z monitorem

Int add(monitor)

to pozniej nie trzeba przekazywac metodom
miedzy monitorem a intem argumentów bo
sa one widzialne wewnetrzeni wzajemnie
przez ten wskaznik (jest to interesujace)

innym ubocznym tematem przy okazji pisanie tego
byloby dla mnie zastanawianie sie czy trzeba pisac
asserty dla nieustawionych referencji (lepiej nie
pisac by obsluzyl je system ale czy system w runtime bedzie w stanie bezstratnie
podac informacje ktora
referencja jest pusta.. pewnie da sie zrobic

jeszcze innym tematem jest zastanowienie sie co jest podobnie jak w kaszaniastym
pozatym oop a co jest jednak inaczej.. itd

do góry

w sumie nie wiadomo tez czy warto uzywac tego &
- potrzebne to jest nie tyle moze nawet do
rozróznienia typów referencji (jak w c) ale do rozróznienia instancjonowania od
trzymania
fizycznej referencji

Monitor m; //instancjonowanie
Monitor& m; //tylko trzymanie referencji

oraz 2 ew do jawnego rozroznienia kopiowania przez wartosc

void f(Monitor m)
{
moinitor = m; //??
}

od tylko uswtwaiania referencji, mozliwe ze lepiej
to wogole wywalic

i pisac tylko

reference Monitor m;

a przy przypisaniach programista musialby byc jednak swiadomy typu

m=monitor;

czy m po lewej jest encja czy referencja, ale i tak programista w c jest swiadomy
typu symbolu wiec chyba wychodziłoby ze te & wogole mozna wywalic

do góry

> czy m po lewej jest encja czy referencja, ale i tak programista w c jest swiadomy
typu symbolu wiec chyba wychodziłoby ze te & wogole mozna wywalic

no dobra w tym sensie tamten kod mozna uproscic

module Int
references Monitor subsequentMonitor
references Int subsequentInt
instantiates unsigned
reaches Syrkamin (*)

internal unsigned data[4];

internal void produce()
data[0..3]++;

external void run()
produce(),
subsequentMonitor show(),
subsequentInt run();


mozna tez dodac operator do obustronnego sklejania
referencji

x glue y; // obie referencje ustawione

(*) kiedys wspominalem o dwu rodzajach zaleznosci
miedzy modulami "reaches" czyli zwykle linkowanie,
instancjonowanie (tak jak np wewnetrzne instancjonwanie floatow) mozna dopisac trzeci

sposób czyli tego rodzaju fizykalne referencje
do kompletu

do góry

On Thu, 20 Feb 2014 01:27:57 -0800 (PST), g...@g...com
wrote:

>W dniu środa, 19 lutego 2014 20:20:36 UTC+1 użytkownik A. L. napisał:
>
>> rzeczywiscie, powstrzymam sie od komentowania. Zzajeloby mi zbyt duzo
>> czasu ktorego nei mam.
>>
>> Proponuje wyjsc poza SICP i poczytac wiecej. N poczatek Clemensa
>> Szyperskiego, na przykald
>>
>> http://research.microsoft.com/en-us/um/people/cszype
rs/pub/ecoop92.pdf
>
>Produkowanie cyfrowej makulatura wydaje sie rzeczywiscie ciekawym
>zjawiskiem, jednak trudno mi pojac, jak odnosi sie to do
>poruszanego wczesniej tematu.
>
Hm... papier Szyperskiego to "makulatora"?... Ten akurat jest dosyc
czesto cytowany w kontekscie dyskusji o tym ze hermetyzacja i
obiektowosc to zupelnie niezalezne koncepcje. Proponuje jednak
przeczytac

>> SICP jest dsyc zlezala i trudnia ja dzis traktwoac jako solidne
>> zrodlo.
>
>Ma Pan oczywiscie prawo do wlasnej opinii. Jest to jednak
>najlepsza ksiazka dotyczaca programowania, z jaka mialem
>kiedykolwiek stycznosc -- a dzieki temu, ze ujmuje zjawisko
>programowania w ogolnosci, trudno mi sobie wyobrazic, zeby
>mogla sie kiedykolwiek zdezaktualizowac.

Ksiazka byla opubilkowana 30 lat temu; troche to i owo sie zmienilo od
tego czasu. Bardzo jest ciekawa, i owszem, w kontekscie historycznym.
Jakis czas temu MIT zrezygnowalo z uzywania tej ksiazki jako
podrecznika i Scheme jako pierwszego jezyka programwoania; pzresadzili
sie na Pythona.

Mam wiecej ksiazek 30 letnich; czytuje je od czasu do czasu z
nostalgii. Ale z rzeczywistoscia to juz one maja neiiele wspolnego

A.L.

do góry

On Wed, 19 Feb 2014 23:27:39 -0800 (PST), g...@g...com
wrote:

>W dniu czwartek, 20 lutego 2014 04:19:30 UTC+1 użytkownik A. L. napisał:
>> On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
>> wrote:
>>
>> Zarowno hermetyzacja jai i polimorfizm nic nie maja ze soba wspolnego
>> ani nic nie maja wspolnego z obiektowoscia.
>
>Przepraszam, ze sie powolam na to zrodlo, ale wydaje mi sie, ze
>ono dosc dobrze reprezentuje "powszechne mniemanie" (i ma te zalete,
>ze jezeli uwazasz, ze jest pelne glupot, a Ty wiesz lepiej, to
>mozesz samemu to poprawic):
>http://en.wikipedia.org/wiki/Object-oriented_progra
mming,
>tamze:
>
>An object is an abstract data type with the addition
>of polymorphism and inheritance.
>
>i dalej:
>
>Object orientation eases maintenance by the use of
>encapsulation and information hiding.
>

To ze Wikipedia tak sobei uwaza, to nei znaczy ze to ejst prawda.

Definicja obiektu minilanla to "struktura posiadajaca tozsamosc, stan
i zachowanie(behavior)". Niczego wiecej od obiektowosci sie nei
wymaga.

Hermetyzacja, polimorfizm i subtyping sa zupelnie neizaleznymi
pojecia,i, ktore i owszem, mozna w OO wykorzystywac. Ale nie ma takiej
koniecznosci.

Posumowujac: akurat w tej dziedzinei Wikipediapisze bzdury

>> Polimorfizm mowi z grubsza o operacjach ktore moba byc zaaplikowane do
>> zmiennych roznych typow, przy czym wlasciwa implementacja wybierana
>> jest automatycznie, stosownie do tych typow.
>[...]
>>
>> Polimorfizm nic nie mowi o "zastepowaniu klas".
>
>Moze tutaj rzeczywiscie wyrazilem sie dosc niefortunnie.
>Chodzilo mi o zastapienie obiektu jednej klasy obiektem
>innej, implementujacej ten sam interfejs. Byl to skrot
>myslowy, ale przyznam, ze nie widze jak inaczej mozna by
>go sensownie interpretowac.
>

To tez nie jest polimorfizm. Proponuje pzreczytac to co napisalem i
sie zastanowic. Zajzrec tez do Wikipedii. Akurat o polimorfizmie
Wikipedia pisze z sensem.

>> Tak na marginesie, interfejs nei okrecla calkowicie zachowanai modulu;
>> moduly o identycznych interfejsach nie musza byc identyczne
>
>To chyba dosc oczywiste?

No, nie sie wydawalo ze Pan postuluje wlasnei to. Nei chce mi sie
szukac ytatu

A.L.

do góry

On Thu, 20 Feb 2014 06:42:13 +0000 (UTC), toslaw <s...@n...4u.pl>
wrote:

>A.L <a...@a...com>:
>> On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
>> wrote:
>>
>> >Wydaje mi sie, ze jezeli chce sie stworzyc system bazujacy
>> >na jakiejs persystencji, to stosowanie analizy obiektowej
>> >jest jak najlepszym pomyslem.
>>
>> [...]
>> Obiekty neispecjalnie dobzre realizujaten koncept - wymagaja
>> serializacji oarz pzreksztalcenia do rozmatu dododnego dla bazy danych
>> (relacyjnego). Model obiektowy i relacyjny nei bardzo do siebie
>> pasuja, i realizacja "persistency" najezona jest trudnosciami. OO
>> wcale nie jest do tego najlepsze
>
>Tak zapytam z ciekawości, jaki jest najlepszy (najwygodniejszy?) sposób na
>zachowywanie obiektów w nośniku stałym (plik, baza danych, etc)?
>

Odpowiedz jest prosta: zaden. Wszystkie maja swoje problemy. Zalezy
zreszta, do czego to jest potzrebne.

De facto standardem dla Javy jest Hibernate. Dosyc upierdliwy, ale
dziala.

>Konkretnie pytam o technikę `serializacji' klasy, aby jej stan móc zrzucić, a
>potem przywrócić w późniejszym czasie, który uważany jest za `najbardziej
>poprawny', i jeśli OO nie jest do tego najlepsze, to co jest?
>
>(nie sugeruję, że uważam, że OO jest do tego najlepsze)

Pytanie jest sformulowane tak ze nie rozumiem,

Java posiada interfejs Serializable ktory wlasnei sluzy do tego.

A.L.

do góry

On Wed, 19 Feb 2014 22:58:54 -0800 (PST), g...@g...com
wrote:

>W dniu czwartek, 20 lutego 2014 04:30:11 UTC+1 użytkownik A. L. napisał:
>> On Wed, 19 Feb 2014 01:58:35 -0800 (PST), g...@g...com
>> wrote:
>>
>> >(A i tak zawsze bedzie mniej elastyczny niz wowczas,
>> >gdy po prostu udostepni sie dobrze napisany kod zrodlowy
>> >-- bo jego elastycznosc bedzie tylko tak duza, na ile
>> >pozwolila wyobraznia jego tworcow)
>>
>> Szczegolnie dobrze sie ten postulat realizuje gdy w grupie jest 20
>> programistow a system ma 5 milionow linii kodu
>
>*Szczegolnie* dobrze sie ten postulat realizuje, gdy w grupie jest 1100+
>programistow, a system ma 15 milionow linii kodu
>
>http://news.cnet.com/8301-1035_3-57603216-94/linux-
development-by-the-numbers-big-and-getting-bigger/

A co to ma wspolnego z tym co napisalem i o czym szla dyskusja?

A.L.

do góry