W dniu 2011-04-15 21:25, f...@g...SKASUJ-TO.pl pisze:
> gregorius<grzegorz.gruza@spamerom_nie.gmail.com> napisał(a):
>
>> W dniu 2011-04-15 19:23, Zbigniew Malec pisze:
>>> On Fri, 15 Apr 2011 19:05:33 +0200, p...@p...onet.pl wrote:
>>>
>>>> a jak to ma wygladac? jest w tym cos szczegolnego - nigdy nie
>>>> uzywalem takiego kodu;
>>>
>>> Koledze chodzi o to (tak podejrzewam), że za uchwytem, oprócz
> identyfikacji
>>> samego pliku, stoi też stan z nim interakcji. Np. na którym bajcie masz
>>> właśnie wskaźnik odczytu pliku itp. Można by każdy taki parametr wyrzucać
>>> na zewnątrz, a potem go z powrotem podawać przy każdym wywołaniu funkcji z
>>> danym plikiem związanej, ale to by było strasznie niewygodne. A tak masz
> to
>>> zaenkapsulowane z dala od niepokojów programisty.
>>>
>>
>> O to właśnie koledze chodzi :-).
>> Ale jak profesor nigdy nie używał takich programów (np. serwerowej bazy
>> danych) to podejrzewam, że ciężko jest mu sobie coś takiego wyobrazić -
>> pewnie stąd jego wątpliwości.
>>
>
> zastanawiam sie czy nie wolalbym by mowic mi raczej per 'GENERALE'
> (generale kenobi) a mniej per 'profesorze' (mozna tez mowic by mi
> per generale w roznych jezykach przyanjmniej nauczylbym sie jak jest
> general w roznych jezykach)

Jak już się zastanowisz to napisz jak mam do Ciebie mówić.

>
> nie jesem zadowolony ze swoich ustalen co do tego jak by nalezalo zrobic
> te odwolania przez identyfikatory - moze olac przesadna moze dbalosc
> o cykle i adresowac przez stringi - nie wiem; oleje chyba jednak
> ten problem pozostajac przy konstatacji ze najlepsze rozwiazanie
> gdzies nienaruszalnie czeka a genaralna zasada by nie przesadzac z uchwytami
> jest ciekawa
>

Wiesz (.... tu se wstaw tytuł, nad się zastanawiasz). Doszedłem do
wniosku, że dla Twoich zastosowań pewnie wystarczyłyby odwołania przez
nazwę. A ta generalna zasada, to może OO?

Pozdrawiam

--
gregorius

do góry

W dniu 2011-04-15 21:58, f...@g...SKASUJ-TO.pl pisze:
>
>> Czy w swoich rozważaniach bierzesz pod uwagę to, że to "x.txt" może być
>> budowane dynamicznie w czasie działania programu?
>> Pytam, bo nie bardzo rozumiem tego ostatniego zdania.
>>
>> Pozdrawiam
>>
>
> tak to chyba nie ma specjalnego znaczenia - trzeba po prostu raz
> w runtime przetlmaczyc "identyfikator" na docelowa z'cache'owana wartosc
> ktora np oznaczam @"identyfikator" - ale troche wnerwia mnie to ze trzeba
> sie w to bawic - cos tu jest nieladnie; np czy ta heca z tymi 'docelowymi
> wartosciami' jest wata wyprawki i czy to naprawde wazne by miec ta liczbe
> - z tymi resourcami moze byc jakos inaczej a ja nie wiem jak o tam
> underlaying w systemie z ymi resourcami jest - gdybym sieskupil to moze
> bym usalil co mnie u wnerwia ale wogle to mam dylemat czy nie lepiej
> zawiesic i olac sprawy poki co - o ile identyfikatorami resorce'ow
> sa nazwy to moze jednak powiny one byc adresowane przez nazwy a z tymi
> wartosciami adresami to jakis humbug
>
>
>
Tak sobie myślę - może zaimplementuj jakąś swoją bibliotekę, gdzie do
dostępu do pliku używa się jego nazwy, a nie uchwytu. Bo póki co to
mówisz, że przez uchwyt jest źle, natomiast to, jak może być lepiej ...
to ja mam pomysł, a wy zrealizujcie go.

Powodzenia

--
gregorius

do góry

On 04/15/2011 08:35 PM, p...@p...onet.pl wrote:
>
>> No i właśnie wymyśliłeś uchwyt. To jest taki "wskaźnik", który mapujesz raz
>> przy użyciu open, a potem używasz w innych wywołaniach. U ciebie akurat
>> jest o tyle gorzej, że dochodzi jeszcze jeden, zupełnie zbędny poziom
>> odniesienia.
>
> mowie, jestem zmeczony i mam troche rzeczy do zrobienia totez nie
> moge wdawac sie w jakies dlugie zastanowienia ale zeby zrekapitulowac
>
> nie jest tak jak to niektorzy tu wspomnieli ze jedyne co sie zyskuje
> to wiekszy koszt niz dostep przez uchwyt - bo to co sie przede
> wszystkim zyskuje to * kompletny brak uchwytow *
>
> jesli pominiemy trudnosci ze zwiekszonymi kosztami
> to wartosc tego rozwiazania polega na tym ze nie ma uchwytow (czasem
> setek uchwytow) i koniec podajesz po prostu nazwy zasobow
>
> sprawa zniesienia kosztow to druga sprawa i robi sie troche trudniej
> ale wydaje sie ze koszt jakiegos
>
> printToFile(resource "x.txt", "zzzz");
>
> wobec
>
> printToFile(h, "zzzz");
>
> nie powinien byc wiekszy bo zasadniczo w pierwszym wypadku mozna zrobic
> 'automatycznie' rzecz podobna do tego co robi sie recznie w drugim wypadku
> (czyli rozwiazanie resourca i zapisanie adresu w pamieci)
> - sa pewne subtelnsci i trudnosci do pokonania - w wiekszosci
> wspomniane tj chodzi o to ze wyrazenie resource "x.txt"
> powinno raz rozwiazac resourca a ozostale razy zwrocic adres - chyba
> zeby zrobic z tego wewnetrzny mechanizm i np wyrazenie
> resourceid "a.txt" powinno robic za nowy typ typu resourceid 'rejestrowany'
> przy pierwszym uzyciu - cos w tym stylu

Taaak... Załóżmy, że w dwóch miejscach w programie czytasz ten sam plik.
W przypadku FILE, każdy z nich ma swój bufor, zapamiętaną swoją pozycję
odczytu i różne inne rzeczy. Gdzie w Twojej bez uchwytowej propozycji te
rzeczy są trzymane?

JD

do góry

On Apr 15, 5:57 pm, Jędrzej Dudkiewicz <jedrzej.dudkiew...@nospam-
gmail.com> wrote:

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

Nie jestem pewny, czy można to tak określić. To nie moja wina, że
jedynym celem działania każdego programu jest modyfikowanie jakiegoś
stanu (jeżeli program nie modyfikuje żadnego stanu, to nie ma po co go
uruchamiać).
Natomiast to, czy logger, semafor, itd. mają być zaszyte w kodzie nie
jest w żaden sposób cechą szczególną OO [*]. Niektórzy starają się to
rozpinać albo wyciągać tego typu zależności poza program (pozdrawiam
miłośników programowania w XMLu), ale tak czy siak jakiś loger musi
być i synchronizacja musi być, itd. - czyli wyciągnięcie czegoś z kodu
zawsze powoduje, że to coś wylezie gdzie indziej.
Jak przysłowiowa plastelina, którą się ściska w dłoni. :-)

[*] Akurat OO daje narzędzia do tego, żeby te zależności wyciągać,
więc krytykowanie OO za istnienie takich zależności jest szczekaniem
na niewłaściwe drzewo.

> Swoją drogą pytanie, jak to rozwiązać, jest dość ciekawe

Ciekawszym pytaniem jest czy w ogóle trzeba to rozwiązywać. Widziałem
przypadki, gdy adaptery i inne takie rozdmuchiwały projekt i same w
sobie wnosiły nowe zależności (np. konieczność ładowania dodatkowych
bibliotek) a nigdy nie było okazji skorzystać z potencjalnych zalet
ich wprowadzenia. Wtedy jest koszt a nie ma zwrotu z inwestycji.
Pytanie jak to przewidzieć.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Wed, 13 Apr 2011 00:02:51 -0700 (PDT), Mariusz
Marszałkowski<m...@g...com> wrote:
> Mam podobne obserwacje w programach w ktorych wazna jest
> wydajna implementacja. Wtedy zdecydowanie wole podejscie
> proceduralne. Poza tym wyjatkiem, podejscie obiektowe zawsze
> mi pomaga.

A w czym właściwie obiektowość przeszkadza wydajnej implementacji?

do góry

On Thu, 14 Apr 2011 22:02:49 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:
> "- inefficient abstracted programming models where two years
> down the road you notice that some abstraction wasn't
> very efficient, but now all your code depends on all the nice
> object models around it, and you cannot fix it without
> rewriting your app.
> In other words, the only way to do good, efficient, and
> system-level and portable C++ ends up to limit yourself
> to all the things that are basically available in C.

Przecież z całego tego tekstu widać, że koleś jest idiotą, który
wypowiada się na tematy, o których nie ma pojęcia.

do góry

>

> Taaak... Załóżmy, że w dwóch miejscach w programie czytasz ten sam plik.
> W przypadku FILE, każdy z nich ma swój bufor, zapamiętaną swoją pozycję
> odczytu i różne inne rzeczy. Gdzie w Twojej bez uchwytowej propozycji te
> rzeczy są trzymane?
>
> JD

ok, uznaje te jak i wspomniane wczesniej trudnosci - (jesli tak jest to
okazuje sie ze taki uchwyt to nie tyle wskaznik na resource co na jakis
bufor do resourca itd) nie zmianiaja jednak ogolnie dobrego sostrzezenia ze w
wywaleniu uchwytow miescilaby sie ew pewna wartosc

proponuje jednak odlozyc ten temat na dluzszy czas (np do czasu az dowiem
sie jak takie resourcy rozwiazuje sie na niskim poziomie), to glebszy temat
a jakmowilem musze zrobic lub przynajmniej postarac sie zrobic w weekend
pewne okropnie zagmatwane rzeczy tak ze wole nie wdawac sie tymczasem az w
tak odrebnie angazujace topiki - zwlaszcza ze i te tez okazuja sie nieco
zagmatwane





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

do góry

> On Thu, 14 Apr 2011 22:02:49 +0200, Wojciech Jaczewski

> <w...@o...pl> wrote:
> > "- inefficient abstracted programming models where two years
> > down the road you notice that some abstraction wasn't
> > very efficient, but now all your code depends on all the nice
> > object models around it, and you cannot fix it without
> > rewriting your app.
> > In other words, the only way to do good, efficient, and
> > system-level and portable C++ ends up to limit yourself
> > to all the things that are  basically available in C.
>
> Przecież z całego tego tekstu widać, że koleś jest idiotą, który
> wypowiada się na tematy, o których nie ma pojęcia.

dodaj jeszcze ze ma "nasrane we lbie" to juz zupelnie pochwalisz
sie swoim poziomem - widocznie w tym temacie jestes specjalista
skoro uzywasz tych okreslen, musi byc ze znasz sie na tym


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

do góry

On 14/04/2011 20:53, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>>> Chciałem. Opamiętanie się, zajęło mi około dwa lata (pracy
>>> zarobkowej + własnych eksperymentów).
>>
>> Wybacz, ale po pierwsze to co piszesz nie przekonuje mnie,
>
> Cóż poradzić.

No, to chyba ty pierwszy użyłeś w tym wątku jako argumentu tego, że w
coś nie wierzysz. :)

>>> Stosowanie rozwiązań modnych ma swoje zalety, ale czasem
>>> warto modę odrzucić.
>> Czasem warto też myśleć o inżynierii w kategoriach innych niż moda.
>
> W takim razie co innego niż moda sprawia, że programowanie obiektowe jest
> tak popularne?

Korzyści, jakie odnosi się w bardzo wielu przypadkach, _zwłaszcza_ w
stosunku do programowania proceduralnego/strukturalnego. Szybsze
tworzenie programów, mniej błędów, ułatwienie współpracy wielu
programistów nad tym samym kodem, lepszy code reuse itd.

>> Można. Tylko że w ten sposób niczego się porządnie nie nauczysz. To
>> tak jakbyś chciał nauczyć się budowy mostów oglądając wszystkie mosty
>> w zasięgu spaceru i eksperymentując z przerzucaniem kładki nad
>> strumykiem.
>
> Dla mnie "porządnie" oznacza, że umiem osiągnąć określony cel. I tę
> umiejętność w dziedzinie programowania w jakimś tam stopniu nabyłem.

Cieszę się niezmiernie, ale "określony cel" to może znaczyć cokolwiek i
nic. "Określony cel" może nawet określić ktoś, kto potrafi napisać tylko
program "Hello World" w BASIC'u na C64.

Z punktu widzenia projektu ważne są różne cele, m.in. takie żeby program
można było łatwo i szybko modyfikować, nie wprowadzając przy tym zbyt
wielu błędów. I w sytuacji, kiedy nad kodem pracuje wielu programistów,
(i powiedzmy mamy możliwość zatrudnienia programistów znających
odpowiednie techniki), to narzucenie użycia technik obiektowych, w
języku wspiejającym obiektowość, znacznie skuteczniej osiąga ten cel niż
robienie tego proceduralnie/strukturalnie.

> Nie wiem dlaczego miałbym się uczyć, jak osiągnąć ten sam cel przy pomocy
> dłuższej, mniej czytelnej, ale za to obiektowej struktury programu.

To się zgadza - nie wiesz.

do góry

Andrzej Jarzabek wrote:

>> Dla mnie "porządnie" oznacza, że umiem osiągnąć określony cel. I tę
>> umiejętność w dziedzinie programowania w jakimś tam stopniu nabyłem.
>
> Cieszę się niezmiernie, ale "określony cel" to może znaczyć cokolwiek i
> nic. "Określony cel" może nawet określić ktoś, kto potrafi napisać tylko
> program "Hello World" w BASIC'u na C64.
>
> Z punktu widzenia projektu ważne są różne cele, m.in. takie żeby program
> można było łatwo i szybko modyfikować, nie wprowadzając przy tym zbyt
> wielu błędów.

Tylko nie można tłumacząc się wizją ewentualnych późniejszych modyfikacji
odwlekać powstania programu, który ma zrealizować założenia, które już w
danym momencie są znane.

> I w sytuacji, kiedy nad kodem pracuje wielu programistów,
> (i powiedzmy mamy możliwość zatrudnienia programistów znających
> odpowiednie techniki), to narzucenie użycia technik obiektowych, w
> języku wspiejającym obiektowość, znacznie skuteczniej osiąga ten cel niż
> robienie tego proceduralnie/strukturalnie.

To jest zawsze coś za coś. Można znacząco zwiększyć zespół, lub znacząco
wydłużyć czas powstawania projektu (tym samym znacząco zwiększając jego
koszt, lub sprawiając że potencjalny zamawiający w ogóle nie będzie
zainteresowany), trzymać się jakiejś ustalonej formy i mniej martwić
ewentualnymi zmianami pracowników. Jest to tym łatwiejsze im mniej
powstanie, dzięki narzuceniu ograniczeń.
Inna opcja to zaryzykować, zrobić coś szybciej, a w razie czego trochę
więcej czasu poświęcić na przejmowanie przez jednego pracownika, tego co
zrobił inny. Trudność jest tu tym większa w porównaniu z bardziej
sformalizowanym sposobem prowadzenia projektu, że do przejęcia jest dużo
więcej - bo to więcej w ogóle miało szansę powstać.

>> Nie wiem dlaczego miałbym się uczyć, jak osiągnąć ten sam cel przy pomocy
>> dłuższej, mniej czytelnej, ale za to obiektowej struktury programu.
>
> To się zgadza - nie wiesz.

Z takimi wypowiedziami kojarzą mi się trafiające się z rzadka dyskusje o
metodologii "agile" (co do której mam stosunek obojętny). Ktoś stosował te
zwyczaje i projekt mu się udał ---> udał się DZIĘKI "agile". Ktoś stosował i
się nie udał ---> stosował "agile" nieudolnie.

do góry