Sure, that is the way we should follow from pharo 4.0 on. Making a modular system means making dependencies visible. If you compose your system there will be parts that are closer to the core and parts which are farther away like applications. The logging is just one thing we need to be closer to the core because it should be usable by core functionality too. May this be a description that suits you more.
Norbert Am 16.06.2014 um 11:05 schrieb kilon alios <[email protected]>: > I think it would be better if pharo was stripped down to core basics , > excluding any logging system as well, and instead the user would be able to > add the functionality he / she wants with configuration browser. I think this > also will show a very clean look highly modular. > > > On Mon, Jun 16, 2014 at 11:57 AM, Tudor Girba <[email protected]> wrote: > Hi Norbert, > > Indeed it was not meant as "I don’t like yours here is mine". > It was meant as "I don’t like yours because ... so here is my concrete > proposal of how to address ..." > > And the goal is not SystemLogger vs Beacon either. The goal should be the one > cool engine that will ship with Pharo 4. > > Doru > > > On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <[email protected]> wrote: > Stef, > > Am 16.06.2014 um 08:52 schrieb stepharo <[email protected]>: > >> >>> Hi, >>> >>> I like very much the new energy people are putting into creating the >>> SystemLogger engine for Pharo. I think this is a specifically important >>> area for which we have to have a solution out of the box. At the same time, >>> I also think that Pharo provides an infrastructure that makes room for >>> ideas that are otherwise hard to reach in other languages or environments. >> >> Why Java does not have announcements? >> >>> Stef asked for collaborations around this project, so here is my literally >>> small contribution: a rather different logging engine. >> I do not see how this contribute to SystemLogger. So at least please do not >> say it, respect the amount of time I spent >> design it and working with Norbert. > > I had troubles myself seeing how this can contribute to SystemLogger. It > looks a lot like „I don’t like yours here is mine“. But if you remember that > is the same reason why you've started SystemLogger. So you should be fair > here. Now it is the time to see how we can benefit from each other. I see it > as an advantage to have code to compare because a lot of discussions are > usual too theoretical to make something of it. > I did not have the time to look at svens and dorus code. But I will because I > had the impression, too, in the beginning that the dispatching of events > would be better done with announcements. We all should review the other > implementations and all of us should be open minded for any reason why the > own implementation is probably _not_ the way to go. > I wish we can find an agreement about an optimal implementation we like to > promote. > > Norbert > > >>> It is called Beacon, it is based entirely on Announcements, it has ~200 >>> lines of code, it has no tags or levels, and in my opinion it is fully >>> functional. >>> >>> You can see a detailed description here including some informal comparisons >>> with SystemLogger: >>> http://www.humane-assessment.com/blog/beacon >>> >>> Please let me know what you think. I would be happy to join forces to reach >>> a mature solution that is both versatile and that can show how Pharo is >>> different. >> So should we see it as a competitor to SystemLogger? >> (you will say of course not) but I do not understand. >> >> >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >
