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?

> 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.

> 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.

> 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ę.

> 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ą? 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.

Powiedz mi, z jakiego powodu nie odtworzyłeś warunków zadania? Ze
złośliwości? 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.

> 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. Tylko że Perl nie jest
statycznie typowany, you know. Nie był przewidziany do takich rzeczy.

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.

--
Secunia non olet.
Stanislaw Klekot