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