> W dniu 2011-04-14 22:17, p...@p...onet.pl pisze:

>

> > uchwyty do resourcow i caly ten stuff z tym, to raczej nie jest OOP :-O

>

>

> JEST

>

> (inny etap, inny jezyk), ale to jest w bezposredniej linii prowadzacej

> do OOP. Te wszystkie Control Bloki, wskazniki na funkcje, szersze wersje

> bloku i wezsze itd. Dziedziczenie, klasa a obiekt,  metody jako takie,

> metody wirtulne, to wszystko tam juz jest.

> To wszystko (poznanie zalet i wad) zaowocowalo OOP. Jezyk obiektowy to

> lepiej obudowal (np. nie bylo wczesniej dobrego 'private' - byly tylko

> konwencje, oraz gwarantowanej poprawnej inicjacji)

>

> Wypowiadasz sie o smaku szpinaku którego nie jadles.

>

Jest dosyc OCZYWISTE ze wypowiadam sie jedynie o FRAGMENCIE
jakiegos zagadnienia (mianowicie o tym fragmencie ktory znam)
<i jest zupelnie mozliwe ze moje zdanie po zaabsorbowaniu wiekszej
czesci uleglo by pewnemu poszerzeniu> ((jest to dosyc oczywiste
dlatego nie ma co wypowiadac tego faktu w charakterze oswiecania
mnie)) - poniekad jest to fragment kondycji czlowieka - wypowiadam
sie o fragmencie ktory znam ale gdy mowie na ten temat to WIEM o
czym mowie - to nie jest problem (wiekszym problemem jest zwykle
morze szumu i glupoty z jakim musze obcowac i ktore i mnie probuje
oglupic albo przyprawia o odpowiednik choroby morskiej)

mam tez swiadomosc ze niektorzy tutaj akurat o niektorych tematach
programistycznych wiedza wiecej ode mnie - ale jesli tak to jakos
nie za bardzo potrafia pprzedstawic te swoje racje, niewazne byc
moze

co do ew pokrewienstwa tematu 'uchwytow do resourcow' z tematem OOP
to 1) jednak nie calkiem jedno i dugie jest tym samym choc jest
pewna paralela 2) nie wiem czy zwolennicy OOP mieli by sie tym ew
pokrewienstwem 'chwalic' bo sam ten temat 'uchwytow do resourcow' niektorzy
wspominaja niekoniecznie dosyc mile - ja sam glownie znam to w wydaniu
np resourcow w winapi (uchwyty do okien gdi itd) i nie jest to chyba
szczytem elegancji raczej chyba niektorzy uwazaja to za 'bigos' czy
'kaszanke' - sam nie zastanawialem sie nad tym na tyle zeby umiec
wyrazniej powiedziec jakie bledy tam sa i jak nalezaloby to poprawic


fir






--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

W dniu 2011-04-15 12:08, panda pisze:
>> W dniu 2011-04-14 22:17, p...@p...onet.pl pisze:

> co do ew pokrewienstwa tematu 'uchwytow do resourcow' z tematem OOP
> to 1) jednak nie calkiem jedno i dugie jest tym samym choc jest
> pewna paralela 2) nie wiem czy zwolennicy OOP mieli by sie tym ew
> pokrewienstwem 'chwalic' bo sam ten temat 'uchwytow do resourcow' niektorzy
> wspominaja niekoniecznie dosyc mile
>

Dlaczego uchwyt a nie wskaznik, kiedy uchwyt a kiedy wskaznik itd. W
czym jest lepszy lub gorszy uchwyt itd. to nie sa jakies nieznane
tematy. To wiedza gdzies tak na drugi semestr.
Wiem, ale nie powiem :P

Uchwyt to mniej wiecej maksimum z designu OOP ktore mozna zrobic w
nieobiektowym jezyku.

Mowi sie, ze ludzie widza drzewa a nie widza lasu. Ale wsrod
programistow sa osoby oraz zbiorowosci (PHP, religijnego C, Delphi) tak
nastawione na szczegól, które juz z drzewem maja problem braku pelnego
widzenia, tylko kora, liscie i igielki.

do góry

> W dniu 2011-04-15 12:08, panda pisze:
> >> W dniu 2011-04-14 22:17, p...@p...onet.pl pisze:
>
> > co do ew pokrewienstwa tematu 'uchwytow do resourcow' z tematem OOP
> > to 1) jednak nie calkiem jedno i dugie jest tym samym choc jest
> > pewna paralela 2) nie wiem czy zwolennicy OOP mieli by sie tym ew
> > pokrewienstwem  'chwalic' bo sam ten temat 'uchwytow do resourcow' niektorzy
> > wspominaja  niekoniecznie dosyc mile
> >
>
> Dlaczego uchwyt a nie wskaznik, kiedy uchwyt a kiedy wskaznik itd. W
> czym jest lepszy lub gorszy uchwyt itd. to nie sa jakies nieznane
> tematy. To wiedza gdzies tak na drugi semestr.
> Wiem, ale nie powiem :P
>
> Uchwyt to mniej wiecej maksimum z designu OOP ktore mozna zrobic w
> nieobiektowym jezyku.
>
> Mowi sie, ze ludzie widza drzewa a nie widza lasu. Ale wsrod
> programistow sa osoby oraz zbiorowosci (PHP, religijnego C, Delphi) tak
> nastawione na szczegól, które juz z drzewem maja problem braku pelnego
> widzenia, tylko kora, liscie i igielki.

widze ze ktos tu osiaga obiektowa harmonie na punkcie uchwytow
i na podlozu lasu mieszanego (sam bylem wczoraj w lesie i zbieralem
galezie brzozowe dla pewnej brunetki tak ze w temacie lasu
niekoniecznie jest mnie latwo zaskoczyc) gdy tymczasem ja stawiam
kwestie czy z tych uchwytow nalezy sie koniecznie tak ciszyc

nigdy sie nad tym nie zastanawialem ale nasuwa mi sie pytanie
czy przypadkiem nie lepiej by bylo gdyby tych uchwytow nie bylo

to jest oddzielna kwestia ale np co do plikow to mozna powiedziec
ze nazwa pliku identyfikuje plik tak ze powstaje pytanie czy zamiast
uzywac tych uchwytow

h = openFile("yoman.txt");

printToFile(h, "jedna rzecz dzis ustalmy");

closeFile(h, "yoman.txt");


nie lepiej byloby uzywac nazw

openFile("yoman.txt");

printToFile("yoman.txt", "jedna rzecz dzis ustalmy");

closeFile("yoman.txt");


bo generalnie z uchwytami zwykle jest pewna kaszanka/bigos
- jest to jednak temat na troche inny watek - wyskoczyl znienacka a mam
teraz w weekend troche innych rzeczy do zrobienia




--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

W dniu 2011-04-15 15:00, fir pisze:
[...]
> nigdy sie nad tym nie zastanawialem ale nasuwa mi sie pytanie
> czy przypadkiem nie lepiej by bylo gdyby tych uchwytow nie bylo

Że się nie zastanawiałeś to faktycznie widać.

[...]
> ze nazwa pliku identyfikuje plik tak ze powstaje pytanie czy zamiast
> uzywac tych uchwytow
[...]
> nie lepiej byloby uzywac nazw
[...]

Świetnie - spróbuj odwoływać się do tego samego pliku zmieniając mu po
drodze nazwę.

[...]
> bo generalnie z uchwytami zwykle jest pewna kaszanka/bigos
[...]

W twojej głowie - na pewno. To można zmienić, ale trzeba chcieć
poczytać ze zrozumieniem.

--
Paweł Kierski
n...@p...net

do góry

> W dniu 2011-04-15 15:00, fir pisze:

> [...]


wogole to ostatnio poduczam sie troche ios'a (polecam zreszta
kazdemu - dopracowane jak cholera i swietne dokumentacje) i moge
dodac ze obawiam sie ze ten ios mnie troche 'koruptuje'
bo przy okazji przykladow typu printToFile("zimny tunczyk.txt", "mniam");
jako programista c zastanawialbym sie nad kosztem w uzywania
dodatkowych stringow - a teraz po tych doswiadczeniach iosowych
troche bardziej jade po powierzchni kladac wiekszy nacisk na druga strone
(tj to ze wprowadzanie uchwytu to realnie powazny minus)




> > nigdy sie nad tym nie zastanawialem ale nasuwa mi sie pytanie

> > czy przypadkiem nie lepiej by bylo gdyby tych uchwytow nie bylo

>

> Że się nie zastanawiałeś to faktycznie widać.

>

> [...]

> > ze nazwa pliku identyfikuje plik tak ze powstaje pytanie czy zamiast

> > uzywac tych uchwytow

> [...]

> > nie lepiej byloby uzywac nazw

> [...]

>

> Świetnie - spróbuj odwoływać się do tego samego pliku zmieniając mu po

> drodze nazwę.

>

w czym problem

openFile("ala.txt");

printToFile("ala.txt", " yo");

renameFile("ala.txt", "linda.txt");

printToFile("linda.txt", " man");

closeFile("linda.txt");

aczkolwiek i handles i nazwy i to i to jest troche uciazliwe
- czasem stosuje sie te struktury z kontekstami i stosami ale
to tez ma swoje minusy... czy resourcy zewnetrzne nalezy mapowac
na strukury w pogramie czy uzywac ich jako zewnetrzne
- zostawiam to na razie do pozniejszego przemyslenia

fir

> [...]

> > bo generalnie z uchwytami zwykle jest pewna kaszanka/bigos

> [...]

>

> W twojej głowie - na pewno. To można zmienić, ale trzeba chcieć

> poczytać ze zrozumieniem.

>

> --

>     Paweł Kierski

>     n...@p...net



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

>... czy resourcy zewnetrzne nalezy mapowac
> na strukury w pogramie czy uzywac ich jako zewnetrzne

to jest pewne pytanie, (instancje typu file to byloby mapowanie
dstep po nazwie pliku bez mapowania a uchwyty cos jakby polsrodek)

> openFile("ala.txt");
> printToFile("ala.txt", " yo");
> renameFile("ala.txt", "linda.txt");
> printToFile("linda.txt", " man");
> closeFile("linda.txt");
>


w "nctx" (new c syntax - o czym kiedys pisalem - czyli o rozwazanej
przeze mnie syntaktycznej nakladce na c byloby to co:

open file "ala txt"
print "yo" to file "ala.txt"
rename file "ala.txt" to "linda.txt"
print " man" to file "linda.txt"
close file "linda.txt"

brzydkie bo kod glupi, pozatym chyba nie takie zle (wziawszy pod uwage ze
c under the hood)

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Apr 15, 9:00 am, Michal Kleczek <k...@g...com> wrote:
>
> Potrzeba wieloparadygmatowosci wydaje sie dzis oczywista. I jezyki
> wieloparadygmatowe (lepsze lub gorsze) istnieja.
>
> Rozumiem te obiekcje i zgadzam sie z nimi - poniekad. Problem jest jednak
> taki, ze narzedzia (czyli jezyki) sa pochodna paradygmatu. OO ma _wlasnie_
> taka zalete, ze istniejace metodyki i wspierajace je narzedzia stanowia
> _spojna_ calosc.
> Jak pisalem w innym poscie - brak "wieloparadygmatowych metodyk" jest dzis
> sporym problemem.

Jak rozumiesz tutaj "metodykę"?

do góry

On 04/15/2011 03:00 PM, fir wrote:
> nigdy sie nad tym nie zastanawialem ale nasuwa mi sie pytanie
> czy przypadkiem nie lepiej by bylo gdyby tych uchwytow nie bylo
>
> to jest oddzielna kwestia ale np co do plikow to mozna powiedziec
> ze nazwa pliku identyfikuje plik tak ze powstaje pytanie czy zamiast
> uzywac tych uchwytow
>
> h = openFile("yoman.txt");
> printToFile(h, "jedna rzecz dzis ustalmy");
> closeFile(h, "yoman.txt");
>
> nie lepiej byloby uzywac nazw
>
> openFile("yoman.txt");
> printToFile("yoman.txt", "jedna rzecz dzis ustalmy");
> closeFile("yoman.txt");

W tym momencie uchwytem jest nazwa pliku. Jedyne, co "zyskałeś", to
strata na szybkości, bo tę nazwę trzeba rozwiązywać na obiekt w systemie.

JD

do góry

Andrzej Jarzabek wrote:

> On Apr 15, 9:00 am, Michal Kleczek <k...@g...com> wrote:
>>
>> Potrzeba wieloparadygmatowosci wydaje sie dzis oczywista. I jezyki
>> wieloparadygmatowe (lepsze lub gorsze) istnieja.
>>
>> Rozumiem te obiekcje i zgadzam sie z nimi - poniekad. Problem jest jednak
>> taki, ze narzedzia (czyli jezyki) sa pochodna paradygmatu. OO ma
>> _wlasnie_ taka zalete, ze istniejace metodyki i wspierajace je narzedzia
>> stanowia _spojna_ calosc.
>> Jak pisalem w innym poscie - brak "wieloparadygmatowych metodyk" jest
>> dzis sporym problemem.
>
> Jak rozumiesz tutaj "metodykę"?

Na przyklad dla OO:
http://en.wikipedia.org/wiki/Shlaer%E2%80%93Mellor_m
ethod
http://en.wikipedia.org/wiki/Booch_method
http://en.wikipedia.org/wiki/Object-oriented_softwar
e_engineering
czy wreszcie (choc to troche cos innego niz "metodyka"):
http://en.wikipedia.org/wiki/Rational_Unified_Proces
s

Lub dla progr. strukturalnego (proceduralnego) wspominana przez A.L:
http://en.wikipedia.org/wiki/Jackson_Structured_Prog
ramming

--
Michal

do góry

On 04/15/2011 09:22 AM, Maciej Sobczak wrote:
> On Apr 15, 12:22 am, Daniel Janus<n...@d...pl> wrote:
>
>> Jeszcze Joe Armstrong, w wywiadzie z Peterem Seibelem w "Coders at Work":
>>
>> I think the lack of reusability comes in object-oriented languages,
>> not in functional languages. Because the problem with object-oriented
>> languages is they've got all the implicit environment that they carry
>> around with them. You wanted a banana but what you got was a gorilla
>> holding the banana and the entire jungle.
>
> WTF? Jaki implicit environment?
> Wszystkie znane mi języki wspierające OO potrzebują jedynie bibliotekę
> run-time - nie różnią się w tym od innych języków. Co prawda języki
> typu zer-runtime istnieją, ale funkcjonalne do nich też nie należą.
> Niektóre języki OO wymagają jeszcze kompilatora, ale w tym też nie
> różnią się od wielu innych języków.

Raczej nie o to chodzi. Ja rozumiem to tak, że masz klasę K, w niej
metodę M, implementacja metody nie jest pure, czyli np. loguje coś klasą
L. L używa do synchronizacji S itd, itp. Jeżeli projekt taki jest, to
faktycznie musisz targać za sobą pół dżungli.

Swoją drogą pytanie, jak to rozwiązać, jest dość ciekawe - akurat co jak
co, ale loggery są praktycznie w każdym projekcie i w praktycznie każdym
są rozwiązane inaczej - mówię o C++ - co oznacza, że idealnie nadają się
do ćwiczenia wzorca projektowego Adapter :)

JD

do góry