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.

--
Pozdrawiam
Zbyszek Malec

do góry

On Fri, 15 Apr 2011 18:51:59 +0200, p...@p...onet.pl wrote:

> a pozniej mozna by probowac
> je wykorzystac a nie robic za kazdym razem - stringi i tak sa przekazywane
> przez adres, trzeba by wiec tylko pozapewniac ze to nie sa odrebne kopie
> tylko ten sam wskaznik

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.

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

W ten sposób wprowadzasz dodatkową składnię do języka, która reprezentuje
pewną funkcjonalność, która nie jest powszechnie używana w samym języku.
Poza tym, jaka wartość dodana jest w twojej propozycji? A jak napiszesz
funkcję, która robi coś na zadanym pliku? Przekażesz napis jako argument?
Czyli dokładnie tak samo jak byś postąpił z uchwytem. Twoje rozwiązanie
niestety nie wnosi nic pozytywnego, a jedynie dodaje kolejny poziom
odniesienia, zaśmieca język oraz jest wolniejsze, niż użycie po prostu
uchwytów.

> - robi to jak widac pewne drobne roznice ale wynika z tego
> ze jest to semantycznie nieco inna rzecz - raczej da sie zrobic; bedzie
> chyba nawet drobinke _szybciej_ niz z uchwytami (bo nie ma uchwytow
> ktorych obsluga to maly koszt) i nie ma uchwytow - sa tylko identyfikatory

Nie będzie szybciej, bo to co proponujesz, to są właśnie uchwyty, tylko że
napisowe, a nie liczbowe i jeszcze ze specjalną składnią w języku. I tak
trzeba w jakiś sposób powiązać mnóstwo informacji wynikającej z danej
interakcji z danym plikiem.
Wspomnę o jeszcze jednym aspekcie, o którym widocznie nie pomyślałeś.
Użycie uchwytów do plików pozwala na takie samo używanie socketów jak i
zwykłych plików, natomiast wprowadzenie uchwytów napisowych powiązanych
tylko ze zwykłymi plikami powoduje koniecznośc istnienia podwójnego api,
jednego do zwykłych plików, które da się nazwać tekstowo oraz drugiego,
związanego z socketami. Że już nie będę wspominał o systemach, gdzie nie ma
czegoś takiego jak nazwa pliku, bo nie ma fizycznie czegoś takiego jak
plik, a są jedynie rekordy w bazie danych.

--
Pozdrawiam
Zbyszek Malec

do góry

> On 04/15/2011 06:10 PM, fir wrote:

> > wywalenie uchwytow upraszczalo by sprawe bo mozna sobie

> > wyobrazic sytuace gdy resourcow jest duzo jest to duzy zbior

> > - z uchwytami sa to dwa zbiory 1) zbior resourcow i 2) zbior uchwytow

> > (przy czym sam zbior uchwytow moze byc schrzaniony - to tak

> > apropos watku roslinnego)

>

> Powtarzam raz jeszcze - uchwyt daje Ci (tylko?) to, że nazwa nie musi być:

>

> a) za każdym razem rozwiązywana na nowo

> b) nie musisz trzymać zasobów niejawnie w jakiejś globalnej tablicy

>

> JD

a)

nazwa nie musi byc rozwiazywana za kazdym razem, musi byc rozwiazana
raz - po czym uzywany identyfikator moze miec juz docelowa wartosc

fakt ze w uzyciu

openFile(@"x.txt")
printToFile(@"x.txt")
closeFile(@"x.txt")

zaciemiona jest asymetria w zwiazku z tym ze przy open jest rozwiazywana
a pozniej juz rozwiazana - ale mozna i na to cos wymyslec np

link_resource("x.txt") //jawny statement do podlinkowania resourca
czy jakies mount(@"x.txt");

tutaj wszystkie @"x.txt" maja juz rozwiazana wartosc


inna opcja o uzywanie zwyklych stringow przez wskazniki - trudno
mi sie zdecydowac ktora z tych opcji jest lepsza a jak mowie nie
mam teraz mozliwosci dluzej tego porozwazac - kluczowym stwierdzeniem
jest to ze nie jest dobrze musiec babrac sie z uchwytami kiedy
wystarcza identyfikatory

b) nie powinienes uzywac nazwy 'global' tylko 'internal'
- to ze te dane nie sa wywlwczone i rozwleczone po uchwytach to
wlasnie zaleta - i tak nie wiem czy np PE nie ma juz jakiejs takiej
tablicy w procesie


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

do góry

> 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










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

do góry

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.

Pozdrawiam

--
gregorius

do góry

W dniu 2011-04-15 19:52, f...@g...SKASUJ-TO.pl pisze:
>> On 04/15/2011 06:10 PM, fir wrote:
[...]
>> a) za każdym razem rozwiązywana na nowo
>
>> b) nie musisz trzymać zasobów niejawnie w jakiejś globalnej tablicy
>
>>
>
>> JD
>
> a)
>
> nazwa nie musi byc rozwiazywana za kazdym razem, musi byc rozwiazana
> raz - po czym uzywany identyfikator moze miec juz docelowa wartosc
>
> fakt ze w uzyciu
>
> openFile(@"x.txt")
> printToFile(@"x.txt")
> closeFile(@"x.txt")
>
> zaciemiona jest asymetria w zwiazku z tym ze przy open jest rozwiazywana
> a pozniej juz rozwiazana - ale mozna i na to cos wymyslec np
>
> link_resource("x.txt") //jawny statement do podlinkowania resourca
> czy jakies mount(@"x.txt");
>
> tutaj wszystkie @"x.txt" maja juz rozwiazana wartosc
[...]
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

--
gregorius

do góry

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)

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

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

do góry

Dnia Fri, 15 Apr 2011 19:25:20 +0000 (UTC), f...@g...SKASUJ-TO.pl
napisał(a):
> 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)

Raczej per 'pacjencie' kenobi.

Grupo szanowna - dajcie już sobie na wstrzymanie, błagam.
Naprawdę trudno zdzierżyć banialuki tego gościa na codzień,
nie musicie go jeszcze podpuszczać.

Waldek

P.S. Znowu zmienił maila i wylazł z KF... ech...

do góry

> 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



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

do góry

> 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



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

do góry