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 <[email protected]> wrote: > > Am 23.02.2014 um 18:54 schrieb Pharo4Stef <[email protected]>: > >> >>> 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 <[email protected]> wrote: >>> >>>> >>>> On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <[email protected]> wrote: >>>> >>>>> >>>>> On 23 Feb 2014, at 12:23, Norbert Hartl <[email protected]> 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 >>>> >>>> >>> >>> >> >> > >
