<div dir="ltr"><div dir="ltr">Hernan,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 23, 2020 at 4:00 PM Hernan Wilkinson <<a href="mailto:hernan.wilkinson@10pines.com">hernan.wilkinson@10pines.com</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"><div dir="ltr"><div dir="ltr">Hi Phil!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 22, 2020 at 2:56 PM Phil B <<a href="mailto:pbpublist@gmail.com" target="_blank">pbpublist@gmail.com</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"><div dir="ltr"><div dir="ltr">Hernan,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 22, 2020 at 4:37 AM Hernan Wilkinson <<a href="mailto:hernan.wilkinson@10pines.com" target="_blank">hernan.wilkinson@10pines.com</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"><div dir="ltr">Hi Phil!,<div> it is interesting what you are proposing. I'd like to understand a little bit more the motivation, why you did it that way, etc., so I have a few questions :-)</div></div></blockquote><div><br></div><div>Before addressing your specific questions, it might be helpful for me to clarify where I'm coming from a bigger picture standpoint:  I don't like how hard coded and brittle much of the infrastructure in Smalltalk is.  I've complained about it before so this should come as no surprise ;-) This is a small step towards addressing one aspect of this.  We have #noteCompilationOf:meta: and no one seems to mind so I thought 'why not extend it so we can have more of a lifecycle view of methods?'  While it's far from a Smalltalk MOP implementation that Alan Kay has talked about, using a mechanism like this seems to me a better approach than either needing to override a number of inconvenient methods and/or baking in features other people many not want to avoid doing said overrides rather than just reacting to method changes as desired.  So by adding a few more hooks around method creation/removal, I can get the functionality I need without either making someone else's life more difficult or my own.</div></div></div></blockquote><div><br></div><div>I agree :-) </div><div>There is the events mechanism to announce about changes in methods, classes, etc., but you can not stop a change for happening with that for example, and your proposal is more oriented to the CLOOS MOP.</div></div></div></blockquote><div><br></div><div>True, but I was only using the MOP as the inspiration.  I'm not pushing for it as the 'be-all, end-all' approach.  If we want to say that the events mechanism is how I'll get the post-change notifications and either we'll extend the notification mechanism or come up with something else for the pre-change notification/approval, 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"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></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"><div dir="ltr"><div>3) Why do you signal an error if compilation is not allowed? That is changing the contract of #compile:... and I'm not sure that an exception is what users of #compile... would expect in that case. Also, in the case of not removing a method you do not signal an exception making the behavior of "not doing" kind of "inconsistent" </div></div></blockquote><div><br></div><div>You are correct that an error was the wrong way to do it and that an exception would be better... I'm fine with changing that.  However, I'm not going to let you take both sides of the argument re: the rest... :-)</div></div></div></blockquote><div><br></div><div>oh! when I said exception I meant any kind of exception. An error is an exception for me :-) </div><div>I'm not sure a specific exception would help... what I mean is that currently #compile:... does not throw an exception/error when something fails, it returns nil. I'm not saying that it is better! just that it changes the behavior of #compile:...</div><div>Also, I'm thinking in a situation where I use the #isOkToCompile to return false when loading code, let's say because the method is trying to compile already exists. An error will be signaled when there is actually no error involved and currently #compile:... returns nil for similar situations.</div><div>I think that if #isOkToCompile returns false, #compile:.. should return nil </div></div></div></blockquote><div><br></div><div>As I indicated in my response to Juan, I don't have any strong feelings as to how we do this.  Only that we do it.  Any place we have code preventing the user or code from making some change to the image (such as adding/changing/removing a class or method), let's instead have a more generalized mechanism that allows for rejecting the requested change and putting that code there instead.  That way if I want different or more/less strict restrictions from someone else, I can get that without causing them problems and vice versa.</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"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Apologies, I didn't state the question/issue very well...</div><div><br></div><div>Look at where the implementors for #noteCompilationOf:meta: and #removeSelector: are.  For #removeSelector: the ClassDescription implementor gets called for instance methods, Behavior for class methods.  Yet for #noteCompilationOf:meta: it's ClassDescription for instance methods and Object (per the method comment) for class methods.  I was expecting more symmetry here (i.e. #noteCompilationOf:meta: essentially being a method add/change and #removeSelector: being method removal) and wondering if there was a reason they ended up where they did or if no one has really thought about it before?  So that's why I put those methods in Object: it seemed like they *should* be needed and functional there. (i.e. I did note the class-side problem ;-)  I don't really care where they go, but the add/change/remove methods  probably should go there together.</div></div></div></blockquote><div><br></div><div>I see... the #noteCompilationOf:meta: in Object class is not needed either as far as I understand it.</div></div></div></blockquote><div><br></div><div>That may have changed over the years... pretty sure it was needed way back when (I think Juan might have added it after I complained about not getting some method changes)</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"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>I think this functionality is interesting, I would add it making the change of #compile:... (not signaling an exception) and without the implementation in Object class (I would remove #noteCompilation... from Object class too). </div></div></div></blockquote><div><br></div><div>Other than being a composite of #methodAdded, #methodAddedInProtocol and #methodChanged messages, do you see any functional difference from what I'd get from SystemChangeNotifier?</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"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Juan, what do you think?</div><div><br></div><div>Hernan.</div></div></div></blockquote><div><br></div><div>Thanks,</div><div>Phil</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>