I would define
OPALCompilationLogEvent as a subclass of Log
and add the information it wants and special behavior identify borken method. I added a description to the chapter and I updated the class comments to reflect that. Stef On 23 Feb 2014, at 19:00, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.02.2014 um 18:54 schrieb Pharo4Stef <pharo4Stef@free.fr>:
But I understand, that is not my point.
Yes I saw it after sending and reading the other mails. This part was made by norbert and it was not obvious to me. Iâm adding the example to the chapter right now.
If it wasnât obvious can you give an example how the OPALCompilationLogEvent would work. Maybe we still have a dissonance here. Is OPALCompilationLogEvent a subclass of Log or ist the log message from opal put into the message of a log or even done with extension?
Norbert
You just need to add a clear example to the docs to make your point, because now you don't, everything is just old school string messages.
On 23 Feb 2014, at 18:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Feb 2014, at 12:23, Norbert Hartl <norbert@hartl.name> wrote:
One of the core ideas is âlogging objects and not stringsâ.
I am missing a clear example of that though.
sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code.
I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event).
In SystemLogger you have
self handleConvertedLogEvent: (self convert: aLogEvent)
and convert: can do what ever we want to convert an object into a string. Stef