<div dir="ltr"><div><div><div><div>I don't like it much. It's not really a Kenel thing.<br></div>For Compiler, that's very simple, remove the logging facility.<br>A Compiler is there to Compile and/or Evaluate, and that's well enough.<br>
</div><div>If you want logging ask any ad-hoc class in the System - Utilities for example (no no! I'm joking).<br></div><div><br></div>For all the Kernel classes wanting to trigger some system change events, I don't know.<br>
</div>Maybe it's a sign that System has to be split.<br>Or we could have kernel methods doing only kernel things, and higher level methods classified in System doing more housekeeping.<br></div><div>Like basicRemoveSelector: (Kernel) vs removeSelector: (System), maybe with better names...<br>
</div><div>Or Behavior>>removeSelector: (Kernel) ClassDescription>>removeSelector: (System)<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/10 Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 9 December 2013 19:34, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
> On 09 Dec 2013, at 0:10, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
><br>
>> Move SystemChangeNotifier to Kernel.<br>
><br>
> 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.<br>
><br>
> Which is why I'd prefer something that didn't bloat up Kernel. Because one day we'll have to untangle Kernel, too.<br>
><br>
> But it does at least rid several packages of their dependency on System.<br>
<br>
</div>Pulling the thread back to its original topic!<br>
<br>
Moving SystemChangeNotifier to Kernel would solve my immediate package<br>
problems, at the cost of<br>
* preserving the inflexible logging<br>
* adding _17_ classes to Kernel.<br>
<br>
I would still prefer to make the Compiler "loggable", so you'd inject<br>
whatever logger you wanted. However, that (a) requires someone to<br>
actually do the work and (b) would take quite a while. Oh, and (c)<br>
mucking around with Compiler means being very careful or breaking<br>
things very badly.<br>
<br>
So I'm kind've +0.5 about moving SystemChangeNotifier to Kernel. It<br>
_does_ remove a bunch of dependencies on System. (Reminder: depending<br>
on System is only bad^Wproblematic because System depends on too many<br>
other packages. If you're one of these packages, hey, cycle time!)<br>
<br>
Step up! Vote!<br>
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> frank<br>
><br>
>> Really, it's something not only the Compiler NEEDS, there's also<br>
>> ClassDescription and ClassOrganizer, and the uses are more than just<br>
>> incidental.<br>
>><br>
>><br>
>> On Sun, Dec 8, 2013 at 4:46 PM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
>>> Compiler depends on System because changing stuff - adding methods,<br>
>>> changing classes, etc. - sends messages to SystemChangeNotifier<br>
>>> uniqueInstance.<br>
>>><br>
>>> While convenient, it (a) is inflexible and (b) causes a cycle. The<br>
>>> correct relationship is that System uses Compiler.<br>
>>><br>
>>> With that in mind, _a_ solution to this problem is to log things<br>
>>> through a callback/registration mechanism of some kind. If you care<br>
>>> about logging, you create a Compiler, say "log here" and off you go.<br>
>>> (This means that you remove the log: part of a lot of methods in<br>
>>> Compiler - if you don't have a logger/loggers attached, nothing<br>
>>> happens, rather than logThis ifTrue: [] blocks. (Because you by<br>
>>> default have a null logger.))<br>
>>><br>
>>> Thoughts? Other possible approaches?<br>
>>><br>
>>> frank<br>
>>><br>
>><br>
<br>
</div></div></blockquote></div><br></div>