<div dir="ltr"><div dir="ltr">Juan,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 23, 2020 at 2:05 PM Juan Vuletich <<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Folks,<br>
<br>
(Hernán, I'm not answering your message, but Phil's original one <br>
because, although I share your curiosity and concerns, I want to answer <br>
in a rather orthogonal way)<br>
<br>
Phil, I think you are raising three completely different issues here <br>
(inline).<br></blockquote><div><br></div><div>Fair enough.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 1/18/2020 8:07 PM, Phil B via Cuis-dev wrote:<br>
> Attached is a first cut of something I've wanted for a while: the <br>
> ability to capture method changes as they occur with the ability to <br>
> prevent them from happening if needed at a global level.  Basically <br>
> it's just paired methods of #isOkTo[Compile|Remove]:meta: and <br>
> #note[Compilation|Removal]Of:meta:.<br>
><br>
> It's always bothered me how central the method  structure is yet <br>
> completely useless from the standpoint of having extensible <br>
> metadata... if I'm wrong re: extensibility, please let me know what <br>
> I've overlooked.  So barring that, these changes allow for things like <br>
> helping to keep a separate metadata structure in sync with method <br>
> changes.  The main requirement is to be able to track method adds, <br>
> changes and deletes to the image globally.  Not sure, but I was <br>
> thinking that this facility might also be useful for refactoring tools.<br>
<br>
Issue 1: Making the infrastructure for rejecting the compilation of a <br>
method more consistent, flexible and extensible. I'm no sure if your <br>
implementation is the best possible (because of Hernán's concerns, and <br>
because it is an ongoing discussion), but I think it is a good idea. If <br>
we can find a way to do it that makes everybody happy, let's go for it.<br></blockquote><div><br></div><div>I'm by no means in love with the solution I came up with.  It mostly worked and seemed to fit in with #noteCompilationOf:meta:.  If that's not how we want to do things going forward, then my approach is a bad solution.</div><div><br></div><div>I don't have any particular preference of how it gets done, just anything that gets us moving away from these embedded behaviors. It's typically just a line or two for the behavior but they're embedded in key methods that will change for other, unrelated reasons which cause my overrides to break.  This is really my primary, and often only complaint, with some of the recently added policies.  I'm fine that they exist in the image and can see how they help some or even most users.  Just give me an easier, less brittle way, to change or disable them if they get in my way.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Issue 2: Allowing interested parties to be notified of changes to code. <br>
Here I don't think we need a new mechanism. We already have <br>
SystemChangeNotifier. See senders of #methodAdded, #methodChanged and <br>
#methodRemoved . I think it is better to use this, and keep enhancing it <br>
as convenient.<br></blockquote><div><br></div><div>I'm OK with that assuming there's no way to (easily/inadvertently) bypass the mechanism.  I was only using #noteCompilationOf:meta: because you pointed me toward it years ago and never got the memo that we were changing. (I suspect you pay closer attention to changesets than I do :-) However, it only provides half of what I'm looking for (i.e. after the change has been made)</div><div><br></div><div>I suspect the other half will probably come with whatever provides the solution to issue 1: whatever mechanism says 'yes, it's OK to do this' could also be used to serve as notification of 'this change is about to happen'</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> One issue / odd thing I noticed: the removal methods only get called <br>
> instance-side due to ClassDescription #removeSelector: only getting <br>
> called on instance methods and you have to jump up to the Behavior <br>
> implementor for class methods.  That seems strange to me since method <br>
> compilation all appears to occur at the level of ClassDescription.  Is <br>
> there a reason removals need to be different from compilation in this <br>
> way?  (Not knowing the answer, I haven't fixed this issue in the <br>
> attached changeset)<br>
<br>
Issue3: Inconsistencies in existing code. WRT #noteCompilationOf:meta: , <br>
I'd just remove it. Users should use SystemChangeNotifier anyway. Other <br>
inconsistencies you see in the code should be discussed and fixed.<br></blockquote><div><br></div><div>I'm OK with that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
<br>
-- <br>
Juan Vuletich<br>
<a href="http://www.cuis-smalltalk.org" rel="noreferrer" target="_blank">www.cuis-smalltalk.org</a><br>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a><br>
<a href="https://github.com/jvuletich" rel="noreferrer" target="_blank">https://github.com/jvuletich</a><br>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a><br>
@JuanVuletich<br>
<br>
</blockquote></div></div>