[squeak-dev] Logging from the Compiler

Chris Muller asqueaker at gmail.com
Thu Dec 12 00:04:29 UTC 2013


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