[squeak-dev] Logging from the Compiler

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Dec 10 21:45:14 UTC 2013


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
> >>>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131210/d2a04d9f/attachment.htm


More information about the Squeak-dev mailing list