<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 19 Nov 2016, at 17:08, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I still thing that the naming is one of the hardest parts:</div><div class="">Imho "@super" just feels wrong — the word has already a meaning, and it should only be used when referring to the parent class (here, it is a restriction/hint for subclasses).</div><div class="">The best I can think of would be @extend (because it is about extension of the marked method)</div></div></div></blockquote><div><br class=""></div><div><div>I like it because it aligns with what you're actually restricting, but obviously all naming is up for debate.</div><div>The use of final for this purpose is okay, but it doesn't really fit the required and optional attributes which I think are also useful to have now or in future.</div><div>@extend is a good possibility though.</div></div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I definitely support the idea in general, so I've something to add:</div><div class="">— There are already cases where super shouldn't be called (<b class="">never</b>?)</div></div></blockquote><div><br class=""></div><div>I can't remember if I had that case in the previous discussion or not, but there's certainly an argument for an additional "never" attribute to prevent the use of super at all!</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">— Imho <b class="">before</b> and <b class="">after</b> only make sense if the call to super is generated automatically when it is omitted: The restriction on the order afaics offers very little (if any) additional safety, and it isn't clear how <i class="">defer</i> would interact with <b class="">before</b>.</div></div></div></blockquote><div><br class=""></div><div>I'm not sure I follow your meaning on omission; I quite like Sean's suggestion of having an override(before) or override(final) in the sub-class, this way the call is explicitly auto-generated. I think having it be added automatically in the regular override case could be a bit confusing, I think a warning or error is better in that case as it should be visible so you know exactly when it is being called, the other cases don't need it (as they have the extra information on the override).</div><div><br class=""></div><div>I forgot all about defer though! They're a bit trickier in the case of @extend(after) or whatever, since deferred statements cannot be executed before the super call. They should be fine in the @extend(before) case though as they can only run after the super method or when it's in the process of throwing without a try. So I suppose it means they will have to produce an error/warning in a regular override if the @extend(after) restriction is present, but should be fine in the override(after) case (implicit super method call after body) assuming the deferred code would execute <b class="">before</b> the super call in that case; since it will resembled its own scope this should be fine I think? Otherwise you need to make sure you perform the defer within a more limited scope in order to control when it eventually executes.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Some questions that should imho be addressed in a formal proposal:</div><div class="">What about parameters and return values? Should it be possible to change those? I think so, but that would make the feature more dangerous than pure monitoring. If it's forbidden to change anything, we loose flexibility, and if it's configurable, complexity is raised.</div></div></blockquote><br class=""></div><div>This is why I think we still need to allow the general override case so we can put the super method wherever we like with an error/warning if breaks any requirement, as developers can add safe code before or after to do any additional processing of parameters/return values. The override(before) and override(after) would just be a shorthand for when you want </div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><div class=""></div><blockquote type="cite" class=""><div class="">On 19 Nov 2016, at 17:29, Mustafa Sabur <<a href="mailto:mustafa.sabur@icloud.com" class="">mustafa.sabur@icloud.com</a>> wrote:</div></blockquote><div class=""><div dir="auto" class=""><blockquote type="cite" class=""><div class="">The most important part is that it should be easy to understand even for beginning developers. Imo the moment someone have to look it up in the docs to understand it, is the moment it has failed to serve its purpose.</div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">I don't think that Sean's override(before/after) should be any more difficult than addinto; in fact it's arguable that addinto doesn't contain enough information as is unclear what's going on as it looks like an entirely new concept, whereas using the override keyword keeps it clear.</div><br class=""><blockquote type="cite" class=""><div class="">I just don't like the fact that you have to use the override keyword while that's not your intention and you can forget to call super. And that it's not guaranteed that you code will run since its not final. </div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Whether or not it's your intention, overriding is what you're doing; I think it's important to keep that clear. I'm not sure what you mean about finality?</div></div></div></div></body></html>