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