On Thu, Dec 12, 2013 at 1:59 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

> 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?
>

I like the Announcements route.  SystemChangeNotifier is a dog.
 Compatibility with Pharo is in the long-term very important (but it has to
be a two-way street, and not blind).


> 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
> >>> >>>
> >>> >>
> >>>
> >>
> >>
> >>
> >>
> >
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131212/168b6ee7/attachment.htm