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