<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 1:59 AM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That is largely true, but I have a little voice in my head screaming<br>
"no! no! no!" because the change is just too easy.<br>
<br>
So far we have +1.5 from Chris and I, and -1 from Nicolas. Eliot?<br></blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Bert? Everyone else?<br>
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 12 December 2013 00:04, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
> Moving it to Kernel scratches the immediate dependency itch without<br>
> inhibiting any future ideas. There's no rush. There's plenty of time<br>
> to think about and discuss changing it into something that can<br>
> satisfies everyone's functional and aesthetic needs.<br>
><br>
> On Tue, Dec 10, 2013 at 3:45 PM, Nicolas Cellier<br>
> <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
>> I don't like it much. It's not really a Kenel thing.<br>
>> 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>
>> If you want logging ask any ad-hoc class in the System - Utilities for<br>
>> example (no no! I'm joking).<br>
>><br>
>> For all the Kernel classes wanting to trigger some system change events, I<br>
>> don't know.<br>
>> 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<br>
>> methods classified in System doing more housekeeping.<br>
>> Like basicRemoveSelector: (Kernel) vs removeSelector: (System), maybe with<br>
>> better names...<br>
>> Or Behavior>>removeSelector: (Kernel) ClassDescription>>removeSelector:<br>
>> (System)<br>
>><br>
>><br>
>> 2013/12/10 Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>><br>
>>><br>
>>> 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<br>
>>> > just SystemChangeNotifier that would need to move though: all of<br>
>>> > 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<br>
>>> > 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>
>>> 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>
>>><br>
>>> frank<br>
>>><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>><br>
>>> >> 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>
>><br>
>><br>
>><br>
>><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>