<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 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><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 ;-) </div></div></div></blockquote><div><br></div><div>:-)</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> 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></div></blockquote><div><br></div><div>I'd like to mention that this two things can be solved using the events infrastructure.</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></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><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 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><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></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><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><br></div><div>Juan, what do you think?</div><div><br></div><div>Hernan.</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><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>
</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></div>