[squeak-dev] Logging from the Compiler

Frank Shearar frank.shearar at gmail.com
Thu Dec 12 09:59:16 UTC 2013


That is largely true, but I have a little voice in my head screaming
"no! no! no!" because the change is just too easy.

So far we have +1.5 from Chris and I, and -1 from Nicolas. Eliot?
Bert? Everyone else?

frank

On 12 December 2013 00:04, Chris Muller <asqueaker at gmail.com> wrote:
> Moving it to Kernel scratches the immediate dependency itch without
> inhibiting any future ideas.  There's no rush.  There's plenty of time
> to think about and discuss changing it into something that can
> satisfies everyone's functional and aesthetic needs.
>
> On Tue, Dec 10, 2013 at 3:45 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> I don't like it much. It's not really a Kenel thing.
>> For Compiler, that's very simple, remove the logging facility.
>> A Compiler is there to Compile and/or Evaluate, and that's well enough.
>> If you want logging ask any ad-hoc class in the System - Utilities for
>> example (no no! I'm joking).
>>
>> For all the Kernel classes wanting to trigger some system change events, I
>> don't know.
>> Maybe it's a sign that System has to be split.
>> Or we could have kernel methods doing only kernel things, and higher level
>> methods classified in System doing more housekeeping.
>> Like basicRemoveSelector: (Kernel) vs removeSelector: (System), maybe with
>> better names...
>> Or Behavior>>removeSelector: (Kernel) ClassDescription>>removeSelector:
>> (System)
>>
>>
>> 2013/12/10 Frank Shearar <frank.shearar at gmail.com>
>>>
>>> On 9 December 2013 19:34, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> > On 09 Dec 2013, at 0:10, Chris Muller <asqueaker at gmail.com> wrote:
>>> >
>>> >> Move SystemChangeNotifier to Kernel.
>>> >
>>> > Well that's certainly a step at least approximately forwards. It's not
>>> > just SystemChangeNotifier that would need to move though: all of
>>> > System-Change Notifications and System-Object Events would have to move too.
>>> >
>>> > Which is why I'd prefer something that didn't bloat up Kernel. Because
>>> > one day we'll have to untangle Kernel, too.
>>> >
>>> > But it does at least rid several packages of their dependency on System.
>>>
>>> Pulling the thread back to its original topic!
>>>
>>> Moving SystemChangeNotifier to Kernel would solve my immediate package
>>> problems, at the cost of
>>> * preserving the inflexible logging
>>> * adding _17_ classes to Kernel.
>>>
>>> I would still prefer to make the Compiler "loggable", so you'd inject
>>> whatever logger you wanted. However, that (a) requires someone to
>>> actually do the work and (b) would take quite a while. Oh, and (c)
>>> mucking around with Compiler means being very careful or breaking
>>> things very badly.
>>>
>>> So I'm kind've +0.5 about moving SystemChangeNotifier to Kernel. It
>>> _does_ remove a bunch of dependencies on System. (Reminder: depending
>>> on System is only bad^Wproblematic because System depends on too many
>>> other packages. If you're one of these packages, hey, cycle time!)
>>>
>>> Step up! Vote!
>>>
>>> frank
>>>
>>> > frank
>>> >
>>> >> Really, it's something not only the Compiler NEEDS, there's also
>>> >> ClassDescription and ClassOrganizer, and the uses are more than just
>>> >> incidental.
>>> >>
>>> >>
>>> >> On Sun, Dec 8, 2013 at 4:46 PM, Frank Shearar <frank.shearar at gmail.com>
>>> >> wrote:
>>> >>> Compiler depends on System because changing stuff - adding methods,
>>> >>> changing classes, etc. - sends messages to SystemChangeNotifier
>>> >>> uniqueInstance.
>>> >>>
>>> >>> While convenient, it (a) is inflexible and (b) causes a cycle. The
>>> >>> correct relationship is that System uses Compiler.
>>> >>>
>>> >>> With that in mind, _a_ solution to this problem is to log things
>>> >>> through a callback/registration mechanism of some kind. If you care
>>> >>> about logging, you create a Compiler, say "log here" and off you go.
>>> >>> (This means that you remove the log: part of a lot of methods in
>>> >>> Compiler - if you don't have a logger/loggers attached, nothing
>>> >>> happens, rather than logThis ifTrue: [] blocks. (Because you by
>>> >>> default have a null logger.))
>>> >>>
>>> >>> Thoughts? Other possible approaches?
>>> >>>
>>> >>> frank
>>> >>>
>>> >>
>>>
>>
>>
>>
>>
>


More information about the Squeak-dev mailing list