<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">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 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>1) Do you have a real case scenario for this feature? I'd like to know the use that we could give it. I would like other peoples opinion on this too because it is a change in the core.</div></div></blockquote><div><br></div><div>Of course! (I never proposes changes that I don't have a need for ;-)  The main categories of use cases I have in mind are:</div><div><br></div><div>1) One wants to track senders or implementors of arbitrary methods at an aggregate level.  These can be relatively expensive things to compute, especially in bulk.</div><div><br></div><div>2) One wants to keep metadata of particular senders/implementors of a method in sync/updated as the image changes.  Some of this metadata may alter the behavior in other parts of the image, including potentially regenerating/recompiling code elsewhere.</div><div><br></div><div>3) Allow for (partially) fixing one of my long standing gripes about the image (see my response to your #3 below)</div><div><br></div><div>One of the things I'm continually running into is that the runtime structure of the image is just too brittle.  Sure, you can dynamically add/remove methods, but the mechanism for having other code react to these changes in realtime, and/or at a global level, is lacking.  This is what these proposed additions are attempting to address.</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>2) Why would not only redefine #compile:... and #removeSelector: for the classes that you need that behavior? (it is related with 1) and I think I know what your answer will be, but I ask just in case :-) )</div></div></blockquote><div><br></div><div>That would work if all you wanted to do is track *a* sender/implementor of a method in a given class hierarchy, but not *all* senders/implementors of it (and there may not be an 'it': you might just need to track everything that is changing) across the image.  Put another way, the solution you suggest addresses it from a class-centric perspective, my proposal allows for addressing it more from a message-centric perspective.</div><div><br></div><div>The methods I'm proposing to add are all similar to #noteCompilationOf:meta: in that when you need them, they are pretty much the only way I can see to efficiently and reliably do it.  While we could potentially re-implement some existing functionality using it (again, see #3 below) I am not proposing any new use cases for it in the base image.  So they're essentially just hooks for those who need the functionality.  Anyone who doesn't care can just ignore them as they do currently with #noteCompilationOf:meta:.  (i.e. it's infrastructure, not a feature)</div><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><br></div><div>This is pretty much providing identical functionality to the existing hard coded warnings/errors in the image when you attempt to override particular key/core methods and classes.  In addition to breaking a contract, the hard-coded rules seem rather antithetical to the Smalltalk philosophy.  My proposal doesn't really allow for the breaking of anything new, just changing the way in which one breaks the contract to allow for it to be done in a user defined/overridden and dynamic way.</div><div><br></div><div>I would greatly appreciate it if things like ClassBuilder name:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category:unsafe: (granted this is for classes, but is an example of the general complaint) and the variable shadowing errors operated more like this.  So that's where the idea for the #isOK* methods came from: let's move policies like these into this method and if I don't like them or need different ones, I have something more straightforward and less brittle to override.</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>4) The redefinition of #isOkToCompile:meta, #isOkToRemove:meta: and #noteRemovalOf:meta: in Object class are not necessary, as far as I can see, why did you redefine them there?</div></div></blockquote><div><br></div><div>I was following the lead of the #noteCompilationOf:meta: Object override here.  This is related to my query related to #removeSelector: that follows...</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><br></div><div>About your question of #removeSelector:, I don't quite understand you question, I think you are missing the meta class part there. I mean, I you have class XX and it has a class method, let's say #m1 and you want to remove it, you have to do:</div><div>XX class removeSelector: #m1</div><div><br></div><div>The method that will be evaluated for that message send will be the one implemented in ClassDescription, as with a class because Metaclass and Class are subclasses of ClassDescription.</div><div>Does it make sense what I'm saying? or am I not understanding your question?</div></div></blockquote><div><br></div><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><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><br></div><div>Cheers!</div><div>Hernan.</div></div></blockquote><div><br></div><div>Thanks,</div><div>Phil</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><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 18, 2020 at 8:08 PM Phil B via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</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">Attached is a first cut of something I've wanted for a while: the ability to capture method changes as they occur with the ability to prevent them from happening if needed at a global level.  Basically it's just paired methods of #isOkTo[Compile|Remove]:meta: and #note[Compilation|Removal]Of:meta:.<div><br></div><div>It's always bothered me how central the method  structure is yet completely useless from the standpoint of having extensible metadata... if I'm wrong re: extensibility, please let me know what I've overlooked.  So barring that, these changes allow for things like helping to keep a separate metadata structure in sync with method changes.  The main requirement is to be able to track method adds, changes and deletes to the image globally.  Not sure, but I was thinking that this facility might also be useful for refactoring tools.<br><div><br></div><div>One issue / odd thing I noticed: the removal methods only get called instance-side due to ClassDescription #removeSelector: only getting called on instance methods and you have to jump up to the Behavior implementor for class methods.  That seems strange to me since method compilation all appears to occur at the level of ClassDescription.  Is there a reason removals need to be different from compilation in this way?  (Not knowing the answer, I haven't fixed this issue in the attached changeset)</div></div></div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal"><span style="font-weight:bold">Hernán Wilkinson</span><br>Agile Software Development, Teaching & Coaching</span></font></span></span></span></strong></span></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">Phone: +54-011</span></font></span></span></span></strong></span><font face="tahoma, sans-serif" size="2">-4893-2057</font></div><div><strong style="font-family:tahoma,sans-serif;font-size:xx-small"><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Twitter: @HernanWilkinson</span></font></span></span></strong></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">site: <a href="http://www.10pines.com/" style="color:rgb(17,65,112)" target="_blank">http://www.10Pines.com</a></span></font></span></span></span></strong></span></div><div><font face="tahoma, sans-serif"><span style="border-collapse:collapse">Address: Alem 896</span></font>, Floor 6, Buenos Aires, Argentina</div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div></div>