On 22/01/2013 22:34, Stachu 'Dozzie' K. wrote:
>
> Właśnie z powodu skali dość często programuję, a między językami się

To jesteś programistą.

do góry

W dniu 2013-01-22 22:33, Stachu 'Dozzie' K. pisze:
> On 2013-01-22, darekm <d...@e...com> wrote:
>>>>> Proszę bardzo, jedziesz. Ja w Perlu robię tak:
>>>>> #v+
>>>>> $logger->warn(msg "coś się zepsuło",
>>>>> file => $filename, errorcode => $?, warning => $msg);
>>>>> #v-
>>>>>
>>>>> Masz obiekt loggera z metodą do wysyłania ostrzeżeń. Potrzebujesz podać:
>>>>> 1) własny komunikat
>>>>> 2) nazwę pliku, którego np. otwarcie sprawiło problem
>>>>> 3) kod błędu (errno lub analogiczny)
>>>>> 4) treść komunikatu od systemu
>>>>> Uwagi:
>>>>> * 4) może zawierać cokolwiek i nie masz nad tym kontroli
>>>>> * wpis w logu ma być czytelny dla człowieka i maszyny
>>>>> * masz w kodzie móc dodać kolejne pola ad-hoc, bez edycji w innych
>>>>> plikach czy miejscach bieżącego pliku
> [...]
>>> Oczywiście. Drzewa zasłaniają ci las.
>>>
>>> Nie interesuje mnie czas życia tego stringa. Nie interesuje mnie
>>> przeciążanie funkcji warn, zwłaszcza że ona powinna być biblioteczna.
>>> To, co mnie interesuje, to definiowanie pól w komunikacie ad-hoc,
>>> w miejscu, w którym tworzę komunikat. *Bez przygotowań*, w tym bez
>>> deklarowania dodatkowych zmiennych tylko na potrzeby logowania.
>
>> Prawdopodobnie wcale nie interesuje Cie jakiekolwiek rozwiązanie tego
>> problemu.
>
> Oczywiście że interesuje mnie. Interesuje mnie rozwiązanie problemu,
> który postawiłem. Mam utworzyć wpis i ten wpis posłać do miejsca
> składowania logów. Po co mi do tego zadania znać jest czas życia obiektu
> reprezentującego wpis?

Każdy byt ma swój czas życia, wpis również, tyle że czas niektórych
jest regulowany automatycznie, a innych ręcznie (przez programistę).

Szczególnie jest to istotne przy wołaniach asynchronicznych. Gdy chcę
aby rzeczywisty wpis do pliku odbywał się poza ścieżką krytyczną, gdy
jest więcej czasu.

Poza tym piszesz:
"Mam utworzyć wpis i ten wpis posłać do miejsca składowania logów"

Rozumiem że:
1. Do miejsca składowania logów posyłam tylko teksty
2. Sposób tworzenia wpisu jest nieistotny, istotna jest notacja poleceń
3. Możesz zdefiniować: "ma być czytelny dla człowieka i maszyny"



>
>> Istotna jest jedynie elastyczność rozwiązania, komplikacja zapisu oraz
>> uzyskany efekt. Nieistotne jest czy to jest funkcja biblioteczna,
>
> Nieistotne? Powiedziałbym że całkiem ważne. Ja nie chcę *pisać* loggera,
> ja chcę go *użyć*. Znaczy -- powinien pochodzić z gotowej biblioteki.\

Dla mnie nieistotne.

>
>> Nie interesuje Cię czas życia, bo nie masz na to wpływu,
>> nie interesuje Cię przeciążanie bo nie Perl nie ma takich możliwości
>
> Perl nie ma możliwości przeciążania? Mówisz o wywoływaniu funkcji
> z różnymi typami parametrów czy o zmianie znaczenia operatorów
> zdefiniowanych w języku dla własnych typów? Bo oba w Perlu występują
> i nie wiem do czego pijesz.

Mówię o różnych funkcjach dla różnych parametrów przy tej samej nazwie.

>
>> A mnie nie interesuje aby była biblioteczna, bo mam różne oczekiwania co
>> do logowania w zależności od rodzaju aplikacji/platformy.


>
> A jakie, że nie da się tego zawrzeć w bibliotece? Ja sobie takich nie
> wyobrażam, ale ja głównie piszę daemony i programy wierszopoleceniowe,
> więc mam dość wąską perspektywę.

Pewnie dlatego. Oprócz powyższych mam jeszcze webowe i desktopowe.


>
>> Ale mimo to przykładowa notacja (kilka wariantów):
>>
>> logger.warn( "coś się zepsuło"
>> +'file'+FileName+eol
>> +logger.param('errorcode,e.errorcode)
>> +'obiekt=>'+logger.asAddress(myClass)
>> +'warning=> uwaga');
>>
>> mogę przesłać wszystko, dowolną ilość pól,
>> nic nie deklaruję
>> mogę przesłać teksty i obiekty
>
> Ah so. I twoim zdaniem taki ręcznie sklejony string jest *równoważny*
> przekazaniu loggerowi wpisu ze strukturą?

A nie jest?
Nie ma problemu (ja nie mam) przekazania dowolnej struktury. XML, JSON
tak działa.

Nawet się nie upieram żeby ta
> struktura była zagnieżdżona. Nie będę nagle wprowadzać nowego warunku,
> skoro poprzednio o nim zapomniałem.

Nie ma problemu z zagnieżdżeniami, kwestia konwencji


>
> Powiedz mi, z jakiego powodu nie odtworzyłeś warunków zadania? Ze
> złośliwości?

Których warunków? Może czegoś nie wiesz i wydaje Ci się że czegoś nie
uzyskam. Albo udowodnij a nie wypisuj inwektyw.
Daj konkretny przykład czego nie da się przekazać. Tzn strukturę w
programie oraz oczekiwany wynik w logu.

Przez przeoczenie? Czy byłeś za głupi żeby zadanie
> zrozumieć? Wolałbym nie zakładać ostatniej możliwości, bo ta gałąź wątku
> byłaby bezsensowna od samego początku.
>
>> funkcja może być biblioteczna, z takiej czy innej biblioteki :
>> rozmawiamy o możliwościach języka
>
> O możliwościach języka, ale na podstawie konkretnego scenariusza użycia.

OK to podaj założenia i oczekiwany wynik.

>
>> A mogę dołożyć własne wymagania:
>> nazwie pliku musi zawsze towarzyszyć jego zawartość (albo analogicznie
>> inna korelacja danych sprawdzana w momencie kompilacji: chodzi o to aby
>> zminimalizować błędy niepełnego wysłania informacji do loggera)
>
> Da się zrobić. Tak, bez uruchomienia kodu (zakładając, że nie liczymy
> funkcji eval) i bez ręcznego parsowania Perla.

Może przytoczyć sposób rozwiązania?


Tylko że Perl nie jest
> statycznie typowany, you know. Nie był przewidziany do takich rzeczy.
>

No i co z tego że nie był przewidziany. Delphi też nie było a
dyskutujemy czy coś się da zrobić czy nie.



> Zresztą jestem ciekawy, jak chcesz to zrobić w Delphi utrzymując moje
> wymagania (głównie możliwość dokładania pól ad-hoc), a tym bardziej przy
> twojej propozycji w postaci klejenia stringa, który jest potem
> przekazywany loggerowi.
>

1. mogę zdefiniować szereg funkcji z jednym parametrem ogólnym oraz
dodatkowymi konkretnymi (pierwsza ma zero typowanych)

2.mogę zdefiniować tag o konkretnej strukturze i wprowadzać go
zdefiniowaną funkcją.







--
Darek

do góry

On 2013-01-23, darekm <d...@e...com> wrote:
> W dniu 2013-01-22 22:33, Stachu 'Dozzie' K. pisze:
>> On 2013-01-22, darekm <d...@e...com> wrote:
>>>>>> Proszę bardzo, jedziesz. Ja w Perlu robię tak:
>>>>>> #v+
>>>>>> $logger->warn(msg "coś się zepsuło",
>>>>>> file => $filename, errorcode => $?, warning => $msg);
>>>>>> #v-
>>>>>>
>>>>>> Masz obiekt loggera z metodą do wysyłania ostrzeżeń. Potrzebujesz podać:
>>>>>> 1) własny komunikat
>>>>>> 2) nazwę pliku, którego np. otwarcie sprawiło problem
>>>>>> 3) kod błędu (errno lub analogiczny)
>>>>>> 4) treść komunikatu od systemu
>>>>>> Uwagi:
>>>>>> * 4) może zawierać cokolwiek i nie masz nad tym kontroli
>>>>>> * wpis w logu ma być czytelny dla człowieka i maszyny
>>>>>> * masz w kodzie móc dodać kolejne pola ad-hoc, bez edycji w innych
>>>>>> plikach czy miejscach bieżącego pliku
>> [...]
>>>> Oczywiście. Drzewa zasłaniają ci las.
>>>>
>>>> Nie interesuje mnie czas życia tego stringa. Nie interesuje mnie
>>>> przeciążanie funkcji warn, zwłaszcza że ona powinna być biblioteczna.
>>>> To, co mnie interesuje, to definiowanie pól w komunikacie ad-hoc,
>>>> w miejscu, w którym tworzę komunikat. *Bez przygotowań*, w tym bez
>>>> deklarowania dodatkowych zmiennych tylko na potrzeby logowania.
>>
>>> Prawdopodobnie wcale nie interesuje Cie jakiekolwiek rozwiązanie tego
>>> problemu.
>>
>> Oczywiście że interesuje mnie. Interesuje mnie rozwiązanie problemu,
>> który postawiłem. Mam utworzyć wpis i ten wpis posłać do miejsca
>> składowania logów. Po co mi do tego zadania znać jest czas życia obiektu
>> reprezentującego wpis?
>
> Każdy byt ma swój czas życia, wpis również, tyle że czas niektórych
> jest regulowany automatycznie, a innych ręcznie (przez programistę).

I to jest powód żebym się przejmował niskopoziomowym detalem przy
tworzeniu wpisu do logów? O_o
Przepraszam, ale od tego piszę w językach wyższego poziomu, żeby się nie
martwić o takie rzeczy.

> Szczególnie jest to istotne przy wołaniach asynchronicznych. Gdy chcę
> aby rzeczywisty wpis do pliku odbywał się poza ścieżką krytyczną, gdy
> jest więcej czasu.
>
> Poza tym piszesz:
> "Mam utworzyć wpis i ten wpis posłać do miejsca składowania logów"
>
> Rozumiem że:
> 1. Do miejsca składowania logów posyłam tylko teksty

Skąd ten pomysł? Gdzieś to napisałem? Może doucz się trochę, mój drogi?
Ten ruch się nazywa "structured logging".

> 2. Sposób tworzenia wpisu jest nieistotny, istotna jest notacja poleceń

Generalnie tak. Użycie loggera ma być tak łatwe dla programisty, jak to
tylko możliwe. Utworzenie specjalnej klasy dla wpisu, a potem utworzenie
instancji takiej klasy jest zbyt pracochłonne (m.in. dlatego, że to
wymaga otwarcia dodatkowego miejsca z definicją klasy przy dodawaniu
informacji).

> 3. Możesz zdefiniować: "ma być czytelny dla człowieka i maszyny"

Człowiek ma być w stanie skorzystać z takiego wpisu.
Maszyna ma być w stanie przetwarzać zestawy takich wpisów.

Ale specjalnie dla ciebie rozjaśnię, co ludzie rozumieją zwykle pod tymi
pojęciami.

Binarne formaty serializacji danych nie nadają się, bo człowiek nie jest
w stanie ich odczytać bez pomocy dodatkowych narzędzi.
Binarne formaty serializacji zapisane w formie tekstowej się nie nadają,
bo człowiek nie jest w stanie odczytać *treści* komunikatu, jedynie jego
*kontener*.
Twój ręcznie poskładany string się nie nadaje, bo jest niejednoznaczny.
Istnieje wiele wiadomości, które dają wpis o takiej samej formie.

>>> Istotna jest jedynie elastyczność rozwiązania, komplikacja zapisu oraz
>>> uzyskany efekt. Nieistotne jest czy to jest funkcja biblioteczna,
>>
>> Nieistotne? Powiedziałbym że całkiem ważne. Ja nie chcę *pisać* loggera,
>> ja chcę go *użyć*. Znaczy -- powinien pochodzić z gotowej biblioteki.\
>
> Dla mnie nieistotne.

Bo?

>>> Nie interesuje Cię czas życia, bo nie masz na to wpływu,
>>> nie interesuje Cię przeciążanie bo nie Perl nie ma takich możliwości
>>
>> Perl nie ma możliwości przeciążania? Mówisz o wywoływaniu funkcji
>> z różnymi typami parametrów czy o zmianie znaczenia operatorów
>> zdefiniowanych w języku dla własnych typów? Bo oba w Perlu występują
>> i nie wiem do czego pijesz.
>
> Mówię o różnych funkcjach dla różnych parametrów przy tej samej nazwie.

Aha. No to ma.

>>> A mnie nie interesuje aby była biblioteczna, bo mam różne oczekiwania co
>>> do logowania w zależności od rodzaju aplikacji/platformy.
>
>
>>
>> A jakie, że nie da się tego zawrzeć w bibliotece? Ja sobie takich nie
>> wyobrażam, ale ja głównie piszę daemony i programy wierszopoleceniowe,
>> więc mam dość wąską perspektywę.
>
> Pewnie dlatego. Oprócz powyższych mam jeszcze webowe i desktopowe.

I uważasz że biblioteka loggera nie poradzi sobie z tym? Możesz
uzasadnić swoje stanowisko?

>>> Ale mimo to przykładowa notacja (kilka wariantów):
>>>
>>> logger.warn( "coś się zepsuło"
>>> +'file'+FileName+eol
>>> +logger.param('errorcode,e.errorcode)
>>> +'obiekt=>'+logger.asAddress(myClass)
>>> +'warning=> uwaga');
>>>
>>> mogę przesłać wszystko, dowolną ilość pól,
>>> nic nie deklaruję
>>> mogę przesłać teksty i obiekty
>>
>> Ah so. I twoim zdaniem taki ręcznie sklejony string jest *równoważny*
>> przekazaniu loggerowi wpisu ze strukturą?
>
> A nie jest?

OCZYWIŚCIE ŻE NIE JEST. Jest niejednoznaczny, to po pierwsze. Po drugie,
żeby logger skorzystał ze struktury wiadomości musiałby specjalnie
parsować twojego ręcznie sklejonego stringa. Po trzecie, twój przykład
wygląda jak psu z gardła przez ten płotek konkatenacji, chociaż to już
moje osobiste uprzedzenie do tego typu konstrukcji.

> Nie ma problemu (ja nie mam) przekazania dowolnej struktury. XML, JSON
> tak działa.

Ale to programista musi nakarmić logger takim JSON-em. W perlowym
rozwiązaniu, które podałem jako referencję, to konfiguracja loggera
wybiera, w jakiej formie będzie zapisany log. A logger jest
konfigurowany już przez administratora, nie programistę.

>> Zresztą jestem ciekawy, jak chcesz to zrobić w Delphi utrzymując moje
>> wymagania (głównie możliwość dokładania pól ad-hoc), a tym bardziej przy
>> twojej propozycji w postaci klejenia stringa, który jest potem
>> przekazywany loggerowi.
>>
>
> 1. mogę zdefiniować szereg funkcji z jednym parametrem ogólnym oraz
> dodatkowymi konkretnymi (pierwsza ma zero typowanych)
>
> 2.mogę zdefiniować tag o konkretnej strukturze i wprowadzać go
> zdefiniowaną funkcją.

I które z tych dwóch pozwoli mi uruchomić logger.warn() z parą
("foobar", "a, b c\nDEF\txxx\", ;'") bez przeciążania logger.warn() na
okoliczność obecności "foobar"?

--
Secunia non olet.
Stanislaw Klekot

do góry

>> Szczególnie jest to istotne przy wołaniach asynchronicznych. Gdy chcę
>> aby rzeczywisty wpis do pliku odbywał się poza ścieżką krytyczną, gdy
>> jest więcej czasu.
>>
>> Poza tym piszesz:
>> "Mam utworzyć wpis i ten wpis posłać do miejsca składowania logów"
>>
>> Rozumiem że:
>> 1. Do miejsca składowania logów posyłam tylko teksty
>
> Skąd ten pomysł? Gdzieś to napisałem?

Nie napisałeś więc się dopytuję co pod tym rozumiesz, bo możliwości jest
wiele.

Może doucz się trochę, mój drogi?

miłe


> Ten ruch się nazywa "structured logging".
>

O coś takiego chodzi
http://gregoryszorc.com/blog/category/logging/
czy to:
http://plumberjack.blogspot.com/2012/03/structured-l
ogging.html

i to nie jest tekst?







>> 2. Sposób tworzenia wpisu jest nieistotny, istotna jest notacja poleceń
>
> Generalnie tak. Użycie loggera ma być tak łatwe dla programisty, jak to
> tylko możliwe.

OK

Utworzenie specjalnej klasy dla wpisu, a potem utworzenie
> instancji takiej klasy jest zbyt pracochłonne (m.in. dlatego, że to
> wymaga otwarcia dodatkowego miejsca z definicją klasy przy dodawaniu
> informacji).

nie rozumiem, jakie dodatkowe miejsce, jak utworzenie instancji klasy
może być pracochłonne

>
>> 3. Możesz zdefiniować: "ma być czytelny dla człowieka i maszyny"
>
> Człowiek ma być w stanie skorzystać z takiego wpisu.
> Maszyna ma być w stanie przetwarzać zestawy takich wpisów.

To nie jest definicja tylko życzenie.
Co to dla Ciebie znaczy przetwarzać. Ja mogę przetwarzać dowolnie tekst
i binarkę, wystarczy że jest ustalona struktura.

>
> Ale specjalnie dla ciebie rozjaśnię, co ludzie rozumieją zwykle pod tymi
> pojęciami.


Dziękuję

>
> Binarne formaty serializacji danych nie nadają się, bo człowiek nie jest
> w stanie ich odczytać bez pomocy dodatkowych narzędzi.
> Binarne formaty serializacji zapisane w formie tekstowej się nie nadają,
> bo człowiek nie jest w stanie odczytać *treści* komunikatu, jedynie jego
> *kontener*.

To co się nadaje, możesz wkleić fragment.

> Twój ręcznie poskładany string się nie nadaje, bo jest niejednoznaczny.
> Istnieje wiele wiadomości, które dają wpis o takiej samej formie.
>

Skąd wiesz, podaj przykład.

>>>> Istotna jest jedynie elastyczność rozwiązania, komplikacja zapisu oraz
>>>> uzyskany efekt. Nieistotne jest czy to jest funkcja biblioteczna,
>>>
>>> Nieistotne? Powiedziałbym że całkiem ważne. Ja nie chcę *pisać* loggera,
>>> ja chcę go *użyć*. Znaczy -- powinien pochodzić z gotowej biblioteki.\
>>
>> Dla mnie nieistotne.
>
> Bo?

Bo nie o tym rozmawiamy.

>
>>>> Nie interesuje Cię czas życia, bo nie masz na to wpływu,
>>>> nie interesuje Cię przeciążanie bo nie Perl nie ma takich możliwości
>>>
>>> Perl nie ma możliwości przeciążania? Mówisz o wywoływaniu funkcji
>>> z różnymi typami parametrów czy o zmianie znaczenia operatorów
>>> zdefiniowanych w języku dla własnych typów? Bo oba w Perlu występują
>>> i nie wiem do czego pijesz.
>>
>> Mówię o różnych funkcjach dla różnych parametrów przy tej samej nazwie.
>
> Aha. No to ma.

Pokaż

>
>>>> A mnie nie interesuje aby była biblioteczna, bo mam różne oczekiwania co
>>>> do logowania w zależności od rodzaju aplikacji/platformy.
>>
>>
>>>
>>> A jakie, że nie da się tego zawrzeć w bibliotece? Ja sobie takich nie
>>> wyobrażam, ale ja głównie piszę daemony i programy wierszopoleceniowe,
>>> więc mam dość wąską perspektywę.
>>
>> Pewnie dlatego. Oprócz powyższych mam jeszcze webowe i desktopowe.
>
> I uważasz że biblioteka loggera nie poradzi sobie z tym? Możesz
> uzasadnić swoje stanowisko?
>

To jest dywagowanie, a tu zupełnie zmieniasz kontekst. Dlaczego mam
udowadniać że twój logger zrobi to co ja potrzebuję. Do tego pewnie samo
pojęcie biblioteki jest inne w Delphi i w Perlu.




>>>> Ale mimo to przykładowa notacja (kilka wariantów):
>>>>
>>>> logger.warn( "coś się zepsuło"
>>>> +'file'+FileName+eol
>>>> +logger.param('errorcode,e.errorcode)
>>>> +'obiekt=>'+logger.asAddress(myClass)
>>>> +'warning=> uwaga');
>>>>
>>>> mogę przesłać wszystko, dowolną ilość pól,
>>>> nic nie deklaruję
>>>> mogę przesłać teksty i obiekty
>>>
>>> Ah so. I twoim zdaniem taki ręcznie sklejony string jest *równoważny*
>>> przekazaniu loggerowi wpisu ze strukturą?
>>
>> A nie jest?
>
> OCZYWIŚCIE ŻE NIE JEST. Jest niejednoznaczny, to po pierwsze.

Skąd wiesz. Co na to wskazuje.
W analogiczny sposób składam pliki do podpisu elektronicznego i są
jednoznaczne.

Po drugie,
> żeby logger skorzystał ze struktury wiadomości musiałby specjalnie
> parsować twojego ręcznie sklejonego stringa.

oczywiście, Twoje biblioteki to również robią.
poza tym ustaliliśmy że nieistotne jest co się dzieje w środku loggera -
nieprawdaż?


Po trzecie, twój przykład
> wygląda jak psu z gardła przez ten płotek konkatenacji, chociaż to już
> moje osobiste uprzedzenie do tego typu konstrukcji.

To sobie podaruj uprzedzenia, ja nie mówię o swoich.

>
>> Nie ma problemu (ja nie mam) przekazania dowolnej struktury. XML, JSON
>> tak działa.
>
> Ale to programista musi nakarmić logger takim JSON-em.

nie, wystarczy przyozdobić poszczególne parametry funkcją formatującą,
to nie jest pracochłonne

W perlowym
> rozwiązaniu, które podałem jako referencję, to konfiguracja loggera
> wybiera, w jakiej formie będzie zapisany log.

Oczywiście, u mnie również

A logger jest
> konfigurowany już przez administratora, nie programistę.

Rzecz umowna, każdy program może mieć swoją konfigurację.

>
>>> Zresztą jestem ciekawy, jak chcesz to zrobić w Delphi utrzymując moje
>>> wymagania (głównie możliwość dokładania pól ad-hoc), a tym bardziej przy
>>> twojej propozycji w postaci klejenia stringa, który jest potem
>>> przekazywany loggerowi.
>>>
>>
>> 1. mogę zdefiniować szereg funkcji z jednym parametrem ogólnym oraz
>> dodatkowymi konkretnymi (pierwsza ma zero typowanych)
>>
>> 2.mogę zdefiniować tag o konkretnej strukturze i wprowadzać go
>> zdefiniowaną funkcją.
>
> I które z tych dwóch pozwoli mi uruchomić logger.warn() z parą
> ("foobar", "a, b c\nDEF\txxx\", ;'") bez przeciążania logger.warn() na
> okoliczność obecności "foobar"?
>

dlaczego bez przeciążania - wprowadzasz sztuczne ograniczenia które
nie wynikają z efektywności programowania ani rezultatów

zazwyczaj nie pisze się tekstem, tylko używa zmiennych, przy silnym
typowaniu nie ma problemu rozróżnić funkcji logowania

mogę też zapisać tak
logger.warn(msg
+ logger.asFile("foobar", "a, b c\nDEF\txxx\", ;'"));





--
Darek

do góry

Dnia Tue, 22 Jan 2013 12:54:47 +0000 (UTC), Stachu 'Dozzie' K. napisał(a):

>> Nie znam Perla i nie wiem jak dokladnie interpretowac Twoj przyklad w nim
>> podany, ale Delphi wspiera closure:
>>
>> http://interactiveasp.net/blogs/spgilmore/archive/20
10/06/17/anonymous-methods-and-closures-in-delphi-20
10.aspx
>
> Fajnie, ale gdzie ja mówiłem o domknięciach?

A mowiles, w ostatniej odpowiedzi do Przemka O.

<cytat>
>> W jaki sposób zrobić domknięcie (closure) w Delphi? Jak utworzyć
>> anonimowy hasz, żeby przekazać dodatkowe pola komunikatu loggerowi?

> Jedziesz ogólnikami, identyczny efekt można rozwiązać na wiele sposobów.

Proszę bardzo, jedziesz. Ja w Perlu robię tak:
</cytat>


> Nie odniosłeś się *w ogóle*
> do tego, co napisałem: chcę funkcję logującą, której mogę podać pola
> (pary nazwa-wartość) w dowolny sposób w danym momencie mi potrzebny
> i której mogę te pola podać bez dodatkowych przygotowań, w jednym
> wyrażeniu będącym wywołaniem funkcji logującej.

Prosze bardzo, moge zrobic metode logujaca, tak:

procedure Warn(aArgs : array of TPair<string,TValue>);

ktora przyjmie dowolna liczbe dowolnego typu danych na zasadzie par
key-value, uzycie:

Warn([Arg('FileName',fFileName),Arg('Color', clRed),Arg('Object',
fStringList)]);

gdzie przekazuje lancuch tekstowy, wartosc liczbowa i obiekt

lub

Warn([Arg('Imie',"Stachu'), Arg('Wiek', 15), Arg('Kultura osobista',
False));

etc.

Arg to metoda zdefiniowana w loggerze wygladajaca np. tak:

function Arg(aName : string; aValue : TValue) : TPair<string,TValue>;


> Nawiasem mówiąc, dobrze świadczy o Delphi fakt, że funkcje anonimowe
> i domknięcia zostały dodane raptem dwa lata temu.

I tak i nie. Problemem byl Borland, ktory zbyt dlugo blokowal rozwoj, gdy
odpuscil i sprawe przejal obecny wlasciciel w ciagu 3-4 lat dokonal sie skok
doganiajcy swiat - a nawet przeganiajacy, sa rzeczy niemal (lub calkiem) nie
do zrobienia w innych jezykach/platformach, ktore w Delphi zrobic sie da
latwo.

> Reszta świata ma to powszechnie od lat parunastu, dziękuję bardzo.

Powszechnie od parunastu lat sa domkniecia w pozostalych jezykach? Jestes
tego pewien?

> Ale to takie moje marudzenie o języku, za którym nie przepadam.

To tak jak ja za Perlem. Okropnie nieczytelny koszmarek.

--
pozdro
R.e.m.e.K

do góry

On 2013-01-23, darekm <d...@e...com> wrote:
>>> Szczególnie jest to istotne przy wołaniach asynchronicznych. Gdy chcę
>>> aby rzeczywisty wpis do pliku odbywał się poza ścieżką krytyczną, gdy
>>> jest więcej czasu.
>>>
>>> Poza tym piszesz:
>>> "Mam utworzyć wpis i ten wpis posłać do miejsca składowania logów"
>>>
>>> Rozumiem że:
>>> 1. Do miejsca składowania logów posyłam tylko teksty
>>
>> Skąd ten pomysł? Gdzieś to napisałem?
>
> Nie napisałeś więc się dopytuję co pod tym rozumiesz, bo możliwości jest
> wiele.

W kwestii semantycznej to nie "dopytujesz się", tylko "zakładasz".
Subtelna różnica.

>> Ten ruch się nazywa "structured logging".
>>
>
> O coś takiego chodzi
> http://gregoryszorc.com/blog/category/logging/
> czy to:
> http://plumberjack.blogspot.com/2012/03/structured-l
ogging.html
>
> i to nie jest tekst?

Nie do końca. To dane ze strukturą zserializowane do tekstu. Rozumiesz
różnicę?

> Utworzenie specjalnej klasy dla wpisu, a potem utworzenie
>> instancji takiej klasy jest zbyt pracochłonne (m.in. dlatego, że to
>> wymaga otwarcia dodatkowego miejsca z definicją klasy przy dodawaniu
>> informacji).
>
> nie rozumiem, jakie dodatkowe miejsce, jak utworzenie instancji klasy
> może być pracochłonne

Samo tworzenie obiektu jako takie niekoniecznie jest pracochłonne, ale
jeśli dodanie kolejnego pola, którego dotychczas nie było, ma wymagać
uzupełnienia definicji klasy, to już pracochłonne jest. A jeśli obiektu
nie da się utworzyć in-line w instrukcji konsumującej ten obiekt (coś
w stylu "o = new Foo(); o.add(...); o.add(...);"), to też jest
pracochłonne.

>> Twój ręcznie poskładany string się nie nadaje, bo jest niejednoznaczny.
>> Istnieje wiele wiadomości, które dają wpis o takiej samej formie.
>>
>
> Skąd wiesz, podaj przykład.

Dla przypomnienia:
#v+
logger.warn( "coś się zepsuło"
+'file'+FileName+eol
+logger.param('errorcode,e.errorcode)
+'obiekt=>'+logger.asAddress(myClass)
+'warning=> uwaga');
#v-

Plik (zmienna FileName) może się nazywać tak:
#v+
foo
errorcode:15obiekt=>0xDEADBEEFwarning=>uwaga
coś się zepsułofile/dev/null

#v-

Starałem się zachować formatowanie wyniku z twojego kodu i naprawiłem
składnię przy logger.param() (choć mogło mi nie wyjść, bo zgadywałem).

Zwróć uwagę na znaki nowej linii w nazwie pliku. Teraz nie wiadomo: plik
miał taką głupią (ale jak najbardziej legalną) nazwę czy też to są dwa
osobne wpisy?

Swoją drogą, widać chyba gołym okiem tę drobną przewagę mojej perlowej
konstrukcji? Jako użytkownik loggera nie muszę dbać jeszcze
o formatowanie doklejanych elementów.

>>>>> Istotna jest jedynie elastyczność rozwiązania, komplikacja zapisu oraz
>>>>> uzyskany efekt. Nieistotne jest czy to jest funkcja biblioteczna,
>>>>
>>>> Nieistotne? Powiedziałbym że całkiem ważne. Ja nie chcę *pisać* loggera,
>>>> ja chcę go *użyć*. Znaczy -- powinien pochodzić z gotowej biblioteki.\
>>>
>>> Dla mnie nieistotne.
>>
>> Bo?
>
> Bo nie o tym rozmawiamy.

To o czym rozmawiamy, że ważna jest "elastyczność rozwiązania",
a ewentualna biblioteczność inkryminowanej funkcji już nie?

>>>>> Nie interesuje Cię czas życia, bo nie masz na to wpływu,
>>>>> nie interesuje Cię przeciążanie bo nie Perl nie ma takich możliwości
>>>>
>>>> Perl nie ma możliwości przeciążania? Mówisz o wywoływaniu funkcji
>>>> z różnymi typami parametrów czy o zmianie znaczenia operatorów
>>>> zdefiniowanych w języku dla własnych typów? Bo oba w Perlu występują
>>>> i nie wiem do czego pijesz.
>>>
>>> Mówię o różnych funkcjach dla różnych parametrów przy tej samej nazwie.
>>
>> Aha. No to ma.
>
> Pokaż

Proszę:
http://search.cpan.org/dist/DBI/DBI.pm#selectall_arr
ayref

>>>>> A mnie nie interesuje aby była biblioteczna, bo mam różne oczekiwania co
>>>>> do logowania w zależności od rodzaju aplikacji/platformy.

>>>> A jakie, że nie da się tego zawrzeć w bibliotece? Ja sobie takich nie
>>>> wyobrażam, ale ja głównie piszę daemony i programy wierszopoleceniowe,
>>>> więc mam dość wąską perspektywę.
>>>
>>> Pewnie dlatego. Oprócz powyższych mam jeszcze webowe i desktopowe.
>>
>> I uważasz że biblioteka loggera nie poradzi sobie z tym? Możesz
>> uzasadnić swoje stanowisko?
>>
>
> To jest dywagowanie, a tu zupełnie zmieniasz kontekst. Dlaczego mam
> udowadniać że twój logger zrobi to co ja potrzebuję.

Ę? Zrozumiałem, że zarzucasz (domyślnie: wszystkim) bibliotekom
logującym, ze są nieelastyczne. Miałeś mieć różne oczekiwania co do
logowania w zależności od rodzaju aplikacji/platformy i biblioteki muszą
się z jakiegoś powodu nie nadawać, skoro chcesz pisać własne funkcje
logujące. Chciałem poznać ten powód nienadawania się.

Czy może coś źle zrozumiałem?

> Do tego pewnie samo
> pojęcie biblioteki jest inne w Delphi i w Perlu.

W Perlu nie występuje pojęcie biblioteki. Przez bibliotekę rozumiem
zbiór funkcji, metod, klas i co-tam-jeszcze, który został napisany
w celu ułatwienia pewnego konkretnego zadania czy typu zadań i który
jest przygotowany do użycia w innym programie.

Tu masz cudzą definicję biblioteki, o którą możemy się oprzeć w dalszej
dyskusji: http://en.wikipedia.org/wiki/Library_%28computing%29

>>>>> Ale mimo to przykładowa notacja (kilka wariantów):
>>>>>
>>>>> logger.warn( "coś się zepsuło"
>>>>> +'file'+FileName+eol
>>>>> +logger.param('errorcode,e.errorcode)
>>>>> +'obiekt=>'+logger.asAddress(myClass)
>>>>> +'warning=> uwaga');
>>>>>
>>>>> mogę przesłać wszystko, dowolną ilość pól,
>>>>> nic nie deklaruję
>>>>> mogę przesłać teksty i obiekty
>>>>
>>>> Ah so. I twoim zdaniem taki ręcznie sklejony string jest *równoważny*
>>>> przekazaniu loggerowi wpisu ze strukturą?
>>>
>>> A nie jest?
>>
>> OCZYWIŚCIE ŻE NIE JEST. Jest niejednoznaczny, to po pierwsze.
>
> Skąd wiesz. Co na to wskazuje.

A w jaki sposób obsługujesz choćby znaki nowej linii w nazwie pliku?

Nawiasem mówiąc, mógłbyś się zapoznać ze znakiem zapytania. Wiesz, tym
kończącym zdania pytające. Uzyskasz go za pomocą kombinacji shift+/.

> Po drugie,
>> żeby logger skorzystał ze struktury wiadomości musiałby specjalnie
>> parsować twojego ręcznie sklejonego stringa.
>
> oczywiście, Twoje biblioteki to również robią.

Skąd ten pomysł? O_o
Log::Log4perl potrafi sobie poradzić z ustrukturalizowanymi danymi, nie
musi parsować stringa z powrotem.

> poza tym ustaliliśmy że nieistotne jest co się dzieje w środku loggera -
> nieprawdaż?

Możemy się umówić, że ustaliliśmy. W takim razie nie było zarzutu
o konieczności deserializacji dla korzystania ze struktury w wiadomości.

>>> Nie ma problemu (ja nie mam) przekazania dowolnej struktury. XML, JSON
>>> tak działa.
>>
>> Ale to programista musi nakarmić logger takim JSON-em.
>
> nie, wystarczy przyozdobić poszczególne parametry funkcją formatującą,
> to nie jest pracochłonne

No czyli programista musi nakarmić logger takim JSON-em.

> W perlowym
>> rozwiązaniu, które podałem jako referencję, to konfiguracja loggera
>> wybiera, w jakiej formie będzie zapisany log.
>
> Oczywiście, u mnie również

To pokaż szerszy przykładowy fragment, bo ja tego nie widzę. Pewnie się
zafiksowałem na twoim ręcznym klejeniu stringa.

>>>> Zresztą jestem ciekawy, jak chcesz to zrobić w Delphi utrzymując moje
>>>> wymagania (głównie możliwość dokładania pól ad-hoc), a tym bardziej przy
>>>> twojej propozycji w postaci klejenia stringa, który jest potem
>>>> przekazywany loggerowi.
>>>>
>>>
>>> 1. mogę zdefiniować szereg funkcji z jednym parametrem ogólnym oraz
>>> dodatkowymi konkretnymi (pierwsza ma zero typowanych)
>>>
>>> 2.mogę zdefiniować tag o konkretnej strukturze i wprowadzać go
>>> zdefiniowaną funkcją.
>>
>> I które z tych dwóch pozwoli mi uruchomić logger.warn() z parą
>> ("foobar", "a, b c\nDEF\txxx\", ;'") bez przeciążania logger.warn() na
>> okoliczność obecności "foobar"?
>>
>
> dlaczego bez przeciążania - wprowadzasz sztuczne ograniczenia które
> nie wynikają z efektywności programowania ani rezultatów

Źle to ująłem, pozwól że się poprawię:

I które z tych dwóch pozwoli mi uruchomić logger.warn() z parą
("foobar", "a, b c\nDEF\txxx\", ;'") bez zmuszania _mnie_ jako
_użytkownika_ _loggera_ do przeciążania logger.warn() na
okoliczność obecności "foobar"?

> zazwyczaj nie pisze się tekstem, tylko używa zmiennych, przy silnym
> typowaniu nie ma problemu rozróżnić funkcji logowania
>
> mogę też zapisać tak
> logger.warn(msg
> + logger.asFile("foobar", "a, b c\nDEF\txxx\", ;'"));

Ale ja nie twierdzę że jest problem je rozróżniać. Ja, jako użytkownik
systemu logowania, nie chcę sam wciąż definiować kolejnych wariantów
funkcji logującej, bo to by oznaczało, że muszę mieć otwarte co najmniej
dwa różne miejsca w kodzie naraz. Dołożenie kolejnego pola do komunikatu
nie powinno mnie zmuszać do pracy w więcej niż jednym miejscu (tym
oczywistym: w miejscu, gdzie powstaje komunikat).

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-01-23, R.e.m.e.K <g...@d...null> wrote:
> Dnia Tue, 22 Jan 2013 12:54:47 +0000 (UTC), Stachu 'Dozzie' K. napisał(a):
>
>>> Nie znam Perla i nie wiem jak dokladnie interpretowac Twoj przyklad w nim
>>> podany, ale Delphi wspiera closure:
>>>
>>> http://interactiveasp.net/blogs/spgilmore/archive/20
10/06/17/anonymous-methods-and-closures-in-delphi-20
10.aspx
>>
>> Fajnie, ale gdzie ja mówiłem o domknięciach?
>
> A mowiles, w ostatniej odpowiedzi do Przemka O.
>
><cytat>
>>> W jaki sposób zrobić domknięcie (closure) w Delphi? Jak utworzyć
>>> anonimowy hasz, żeby przekazać dodatkowe pola komunikatu loggerowi?
>
>> Jedziesz ogólnikami, identyczny efekt można rozwiązać na wiele sposobów.
>
> Proszę bardzo, jedziesz. Ja w Perlu robię tak:
></cytat>

A to przepraszam, rzeczywiście postawiłem taki zarzut.

>> Nie odniosłeś się *w ogóle*
>> do tego, co napisałem: chcę funkcję logującą, której mogę podać pola
>> (pary nazwa-wartość) w dowolny sposób w danym momencie mi potrzebny
>> i której mogę te pola podać bez dodatkowych przygotowań, w jednym
>> wyrażeniu będącym wywołaniem funkcji logującej.
>
> Prosze bardzo, moge zrobic metode logujaca, tak:
>
> procedure Warn(aArgs : array of TPair<string,TValue>);
>
> ktora przyjmie dowolna liczbe dowolnego typu danych na zasadzie par
> key-value, uzycie:
>
> Warn([Arg('FileName',fFileName),Arg('Color', clRed),Arg('Object',
> fStringList)]);

...albo Warn([Arg('Foo', Arg('bar', 'baz'))]).

Dziękuję, taką konstrukcję właśnie chciałem zobaczyć. Chociaż nie
podoba mi się wołanie funkcji Arg(), ale to głównie kwestia estetyczna.

Długo już w Delphi występuje typ TValue?

>> Nawiasem mówiąc, dobrze świadczy o Delphi fakt, że funkcje anonimowe
>> i domknięcia zostały dodane raptem dwa lata temu.
>
> I tak i nie. Problemem byl Borland, ktory zbyt dlugo blokowal rozwoj, gdy
> odpuscil i sprawe przejal obecny wlasciciel w ciagu 3-4 lat dokonal sie skok
> doganiajcy swiat - a nawet przeganiajacy, sa rzeczy niemal (lub calkiem) nie
> do zrobienia w innych jezykach/platformach, ktore w Delphi zrobic sie da
> latwo.

Mogę prosić o przykłady?

>> Reszta świata ma to powszechnie od lat parunastu, dziękuję bardzo.
>
> Powszechnie od parunastu lat sa domkniecia w pozostalych jezykach? Jestes
> tego pewien?

W językach imperatywnych -- owszem. Ja wiem, że języki funkcyjne miały
to "troszkę" wcześniej, tylko jakoś słabo z ich użyciem w przemyśle IT.

>> Ale to takie moje marudzenie o języku, za którym nie przepadam.
>
> To tak jak ja za Perlem. Okropnie nieczytelny koszmarek.

A to już zależy kto pisze. Historycznie dużo użytkowników Perla nie
potrafiło programować w Perlu, to głównie stąd opinia o jego
nieczytelności.

--
Secunia non olet.
Stanislaw Klekot

do góry

Dnia Wed, 23 Jan 2013 19:00:14 +0000 (UTC), Stachu 'Dozzie' K. napisał(a):

> ...albo Warn([Arg('Foo', Arg('bar', 'baz'))]).
>
> Dziękuję, taką konstrukcję właśnie chciałem zobaczyć. Chociaż nie
> podoba mi się wołanie funkcji Arg(), ale to głównie kwestia estetyczna.
>
> Długo już w Delphi występuje typ TValue?

Chyba tez od 2010, jak pisalem Borland od lat olewal Delphi i bylo juz na
skraju upadku. Dopiero od 2008/2009 pojawil sie nowy wlasciciel i sprawa
ruszyla z kopyta, najpierw do calego RTLa wszedl unicode (wczesniej trzeba
bylo z tym rzezbic), potem bogate RTTI, class helpery, generyki, closures,
metody w typach rekordowych i duzo innych fajnych rzeczy.
btw to co pokazalem dalo by sie _chyba_ tez zrobic bez TValue, ale byloby
trudniej, a nie mam czasu na kombinacje.

>> I tak i nie. Problemem byl Borland, ktory zbyt dlugo blokowal rozwoj, gdy
>> odpuscil i sprawe przejal obecny wlasciciel w ciagu 3-4 lat dokonal sie skok
>> doganiajcy swiat - a nawet przeganiajacy, sa rzeczy niemal (lub calkiem) nie
>> do zrobienia w innych jezykach/platformach, ktore w Delphi zrobic sie da
>> latwo.
>
> Mogę prosić o przykłady?

Firemonkey - wektorowe GUI, niezaleznego od platformy, wykorzystujace
akceleracje grafiki.
http://en.wikipedia.org/wiki/FireMonkey

Mozliwosc crosskompilacji na Win32, Win64, OSXa. W najblizszych miesiacach
dojdzie kompilacja natywana na iOS i Androida (z pelna obsluga sensorow i
innych "mobilnosci"):
http://edn.embarcadero.com/article/42544

Potem kompilacja na Linuxa, ale to juz chyba 2014.

--
pozdro
R.e.m.e.K.

do góry

On 2013-01-23, R.e.m.e.K <g...@d...null> wrote:
>>> I tak i nie. Problemem byl Borland, ktory zbyt dlugo blokowal rozwoj, gdy
>>> odpuscil i sprawe przejal obecny wlasciciel w ciagu 3-4 lat dokonal sie skok
>>> doganiajcy swiat - a nawet przeganiajacy, sa rzeczy niemal (lub calkiem) nie
>>> do zrobienia w innych jezykach/platformach, ktore w Delphi zrobic sie da
>>> latwo.
>>
>> Mogę prosić o przykłady?
>
> Firemonkey - wektorowe GUI, niezaleznego od platformy, wykorzystujace
> akceleracje grafiki.
> http://en.wikipedia.org/wiki/FireMonkey

OK, I see. Wprawdzie nie nazwałbym tego rzeczą "(niemal) nie do
zrobienia" na innych platformach, ale jako coś już gotowego ma
zdecydowaną przewagę nad czymś, co dopiero potencjalnie się da zrobić.

> Mozliwosc crosskompilacji na Win32, Win64, OSXa.

GCC już to miało, ale jestem skłonny uznać ten punkt.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 2013-01-23 19:49, Stachu 'Dozzie' K. pisze:
> On 2013-01-23, darekm <d...@e...com> wrote:
>>>> Szczególnie jest to istotne przy wołaniach asynchronicznych. Gdy chcę
>>>> aby rzeczywisty wpis do pliku odbywał się poza ścieżką krytyczną, gdy
>>>> jest więcej czasu.
>>>>
>>>> Poza tym piszesz:
>>>> "Mam utworzyć wpis i ten wpis posłać do miejsca składowania logów"
>>>>
>>>> Rozumiem że:
>>>> 1. Do miejsca składowania logów posyłam tylko teksty
>>>
>>> Skąd ten pomysł? Gdzieś to napisałem?
>>
>> Nie napisałeś więc się dopytuję co pod tym rozumiesz, bo możliwości jest
>> wiele.
>
> W kwestii semantycznej to nie "dopytujesz się", tylko "zakładasz".
> Subtelna różnica.
>

I wypisuję założenia byś je zweryfikował.
I jednocześnie mogę dalej pisać przy tychże założeniach. Tu nic nie ma z
wmawiania.

>>> Ten ruch się nazywa "structured logging".
>>>
>>
>> O coś takiego chodzi
>> http://gregoryszorc.com/blog/category/logging/
>> czy to:
>> http://plumberjack.blogspot.com/2012/03/structured-l
ogging.html
>>
>> i to nie jest tekst?
>
> Nie do końca. To dane ze strukturą zserializowane do tekstu. Rozumiesz
> różnicę?

nie

>
>> Utworzenie specjalnej klasy dla wpisu, a potem utworzenie
>>> instancji takiej klasy jest zbyt pracochłonne (m.in. dlatego, że to
>>> wymaga otwarcia dodatkowego miejsca z definicją klasy przy dodawaniu
>>> informacji).
>>
>> nie rozumiem, jakie dodatkowe miejsce, jak utworzenie instancji klasy
>> może być pracochłonne
>
> Samo tworzenie obiektu jako takie niekoniecznie jest pracochłonne, ale
> jeśli dodanie kolejnego pola, którego dotychczas nie było, ma wymagać
> uzupełnienia definicji klasy, to już pracochłonne jest.

Oczywiste jest że jeżeli coś musi być uprzednio zdefiniowane to jest
bardziej pracochłonne, ale tym samym kompilator wyłapie wszelkie
niezdefiniowane konstrukcje czyli znajdzie za nas cześć błędów co jest
znowu mniej pracochłonne czyli kwestia umiejętności stosowania i
statystyki przypadków.

A jeśli obiektu
> nie da się utworzyć in-line w instrukcji konsumującej ten obiekt (coś
> w stylu "o = new Foo(); o.add(...); o.add(...);"), to też jest
> pracochłonne.
>

w jakim celu?
>>> Twój ręcznie poskładany string się nie nadaje, bo jest niejednoznaczny.
>>> Istnieje wiele wiadomości, które dają wpis o takiej samej formie.
>>>
>>
>> Skąd wiesz, podaj przykład.
>
> Dla przypomnienia:
> #v+
> logger.warn( "coś się zepsuło"
> +'file'+FileName+eol
> +logger.param('errorcode,e.errorcode)
> +'obiekt=>'+logger.asAddress(myClass)
> +'warning=> uwaga');
> #v-
>
> Plik (zmienna FileName) może się nazywać tak:
> #v+
> foo
> errorcode:15obiekt=>0xDEADBEEFwarning=>uwaga
> coś się zepsułofile/dev/null
>
> #v-
>
> Starałem się zachować formatowanie wyniku z twojego kodu i naprawiłem
> składnię przy logger.param() (choć mogło mi nie wyjść, bo zgadywałem).

Nigdzie nie powiedziałem że nie będzie prefixów i suffixów i dodatkowego
kodowania przy polach. Nie mogę się dopytać jaki ma być efekt końcowy
więc nie przedstawiłem szczegółów.
Możesz przedstawić oczekiwaną przez Ciebie postać.

>
> Zwróć uwagę na znaki nowej linii w nazwie pliku. Teraz nie wiadomo: plik
> miał taką głupią (ale jak najbardziej legalną) nazwę czy też to są dwa
> osobne wpisy?

Funkcja wypisująca string może stosować odpowiednie kodowanie zgodnie z
przyjętą semantyką.

>
> Swoją drogą, widać chyba gołym okiem tę drobną przewagę mojej perlowej
> konstrukcji? Jako użytkownik loggera nie muszę dbać jeszcze
> o formatowanie doklejanych elementów.

Nie muszę dbać o formatowanie, muszę tylko wybrać odpowiedni "formater"
dla określonych elementów, przy czym może to się odbywać automatycznie
lub ręcznie za decyzją programisty.

>
>>>>>> Istotna jest jedynie elastyczność rozwiązania, komplikacja zapisu oraz
>>>>>> uzyskany efekt. Nieistotne jest czy to jest funkcja biblioteczna,
>>>>>
>>>>> Nieistotne? Powiedziałbym że całkiem ważne. Ja nie chcę *pisać* loggera,
>>>>> ja chcę go *użyć*. Znaczy -- powinien pochodzić z gotowej biblioteki.\
>>>>
>>>> Dla mnie nieistotne.
>>>
>>> Bo?
>>
>> Bo nie o tym rozmawiamy.
>
> To o czym rozmawiamy, że ważna jest "elastyczność rozwiązania",
> a ewentualna biblioteczność inkryminowanej funkcji już nie?
>

Jak coś się da zrobić to się może pojawić w bibliotece. Nie chcę
dyskutować o tym czy to powinno być w bibliotece standardowej,
zakupionej, własnej czy jeszcze innej.


>>>>>> Nie interesuje Cię czas życia, bo nie masz na to wpływu,
>>>>>> nie interesuje Cię przeciążanie bo nie Perl nie ma takich możliwości
>>>>>
>>>>> Perl nie ma możliwości przeciążania? Mówisz o wywoływaniu funkcji
>>>>> z różnymi typami parametrów czy o zmianie znaczenia operatorów
>>>>> zdefiniowanych w języku dla własnych typów? Bo oba w Perlu występują
>>>>> i nie wiem do czego pijesz.
>>>>
>>>> Mówię o różnych funkcjach dla różnych parametrów przy tej samej nazwie.
>>>
>>> Aha. No to ma.
>>
>> Pokaż
>
> Proszę:
> http://search.cpan.org/dist/DBI/DBI.pm#selectall_arr
ayref

To tylko ze względu na liczbę parametrów, trochę mało.

>
>>>>>> A mnie nie interesuje aby była biblioteczna, bo mam różne oczekiwania co
>>>>>> do logowania w zależności od rodzaju aplikacji/platformy.
>
>>>>> A jakie, że nie da się tego zawrzeć w bibliotece? Ja sobie takich nie
>>>>> wyobrażam, ale ja głównie piszę daemony i programy wierszopoleceniowe,
>>>>> więc mam dość wąską perspektywę.
>>>>
>>>> Pewnie dlatego. Oprócz powyższych mam jeszcze webowe i desktopowe.
>>>
>>> I uważasz że biblioteka loggera nie poradzi sobie z tym? Możesz
>>> uzasadnić swoje stanowisko?
>>>
>>
>> To jest dywagowanie, a tu zupełnie zmieniasz kontekst. Dlaczego mam
>> udowadniać że twój logger zrobi to co ja potrzebuję.
>
> Ę? Zrozumiałem, że zarzucasz (domyślnie: wszystkim) bibliotekom
> logującym, ze są nieelastyczne. Miałeś mieć różne oczekiwania co do
> logowania w zależności od rodzaju aplikacji/platformy i biblioteki muszą
> się z jakiegoś powodu nie nadawać, skoro chcesz pisać własne funkcje
> logujące. Chciałem poznać ten powód nienadawania się.
>

Tak jak napisałem. Nie znam wszystkich możliwości twojego loggera więc
nie mogę się na ten temat wypowiadać. Choć możemy podyskutować o
asynchroniczności.




>
>>>>>> Ale mimo to przykładowa notacja (kilka wariantów):
>>>>>>
>>>>>> logger.warn( "coś się zepsuło"
>>>>>> +'file'+FileName+eol
>>>>>> +logger.param('errorcode,e.errorcode)
>>>>>> +'obiekt=>'+logger.asAddress(myClass)
>>>>>> +'warning=> uwaga');
>>>>>>
>>>>>> mogę przesłać wszystko, dowolną ilość pól,
>>>>>> nic nie deklaruję
>>>>>> mogę przesłać teksty i obiekty
>>>>>
>>>>> Ah so. I twoim zdaniem taki ręcznie sklejony string jest *równoważny*
>>>>> przekazaniu loggerowi wpisu ze strukturą?
>>>>
>>>> A nie jest?
>>>
>>> OCZYWIŚCIE ŻE NIE JEST. Jest niejednoznaczny, to po pierwsze.
>>
>> Skąd wiesz. Co na to wskazuje.
>
> A w jaki sposób obsługujesz choćby znaki nowej linii w nazwie pliku?

W zależności od potrzeb, każdy format ( XML, JSON, URL, CSV) może mieć
inne podejście.

>
>>>>> Zresztą jestem ciekawy, jak chcesz to zrobić w Delphi utrzymując moje
>>>>> wymagania (głównie możliwość dokładania pól ad-hoc), a tym bardziej przy
>>>>> twojej propozycji w postaci klejenia stringa, który jest potem
>>>>> przekazywany loggerowi.
>>>>>
>>>>
>>>> 1. mogę zdefiniować szereg funkcji z jednym parametrem ogólnym oraz
>>>> dodatkowymi konkretnymi (pierwsza ma zero typowanych)
>>>>
>>>> 2.mogę zdefiniować tag o konkretnej strukturze i wprowadzać go
>>>> zdefiniowaną funkcją.
>>>
>>> I które z tych dwóch pozwoli mi uruchomić logger.warn() z parą
>>> ("foobar", "a, b c\nDEF\txxx\", ;'") bez przeciążania logger.warn() na
>>> okoliczność obecności "foobar"?
>>>
>>
>> dlaczego bez przeciążania - wprowadzasz sztuczne ograniczenia które
>> nie wynikają z efektywności programowania ani rezultatów
>
> Źle to ująłem, pozwól że się poprawię:
>
> I które z tych dwóch pozwoli mi uruchomić logger.warn() z parą
> ("foobar", "a, b c\nDEF\txxx\", ;'") bez zmuszania _mnie_ jako
> _użytkownika_ _loggera_ do przeciążania logger.warn() na
> okoliczność obecności "foobar"?
>
>> zazwyczaj nie pisze się tekstem, tylko używa zmiennych, przy silnym
>> typowaniu nie ma problemu rozróżnić funkcji logowania
>>
>> mogę też zapisać tak
>> logger.warn(msg
>> + logger.asFile("foobar", "a, b c\nDEF\txxx\", ;'"));
>
> Ale ja nie twierdzę że jest problem je rozróżniać. Ja, jako użytkownik
> systemu logowania, nie chcę sam wciąż definiować kolejnych wariantów
> funkcji logującej, bo to by oznaczało, że muszę mieć otwarte co najmniej
> dwa różne miejsca w kodzie naraz. Dołożenie kolejnego pola do komunikatu
> nie powinno mnie zmuszać do pracy w więcej niż jednym miejscu (tym
> oczywistym: w miejscu, gdzie powstaje komunikat).
>

Nie muszę tylko mogę. Poza standardowymi stringami i liczbami *mogę*
sobie zdefiniować nowe elementy używane w określony sposób.



--
Darek

do góry