<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 17 Feb 2016, at 23:56, Dennis Weissmann &lt;<a href="mailto:dennis@dennisweissmann.me" class="">dennis@dennisweissmann.me</a>&gt; wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Note: I’ve changed the syntax to # because I think this is compiler-magic and as Chris mentioned the following in the property behavior thread:</div></div></div></blockquote><div><br class=""></div><div>Is it compiler magic though? To me compiler magic is something that the compiler does to change your code, for example testing for OS version lets you add code specific to that OS. This wouldn’t actually change anything, it’s really just a directive in how the method should be implemented, personally that puts it closer to attributes such as @warn_unused_result IMO. You cite the case of the property behaviours proposal, however that is a proposal that introduces custom code that the compiler would connect to your properties for you, so it’s undoubtedly compiler magic of a sort.</div><div><br class=""></div><div>If we do go for the hash prefix though, I don’t think that we need #requireSuperStart etc., just a general #requireSuper would do with optional brackets to add more specific requirements as has been proposed with attributes and keywords. That said, I think #requireSuper may be the wrong term, unless your intention was to also have #optionalSuper and #warnSuper? Personally I think it’d be easier to just to #super(required, before, warn) or whatever, same as we’ve been discussing for attributes and keywords, as it groups everything into the one command; there should be no reason we can’t just use super for the naming either since it’s unambiguous (and actually it’s relevant).</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="">The compiler would inject (invisible to the dev) the&nbsp;<span class="" style="color: rgb(187, 44, 162); font-family: Menlo; font-size: 11px;">super</span><span class="" style="font-family: Menlo; font-size: 11px;">()<font color="#bb2ca2" class="">&nbsp;</font></span>call at the very beginning. The same is true for&nbsp;<span class="" style="color: rgb(187, 44, 162); font-family: Menlo; font-size: 11px;">#requireSuperEnd</span>.</div><div class="">I don’t think we need a&nbsp;<span style="color: rgb(187, 44, 162); font-family: Menlo; font-size: 11px;" class="">#requireSuper</span>&nbsp;because it means we don’t care when it’s called so the compiler can decide where to put it.</div></div></blockquote></div><br class=""><div class="">Like others have said I think we should shy away from the compiler adding this for us, as it may introduce debugging issues if someone didn’t notice the requirements and the compiler just went and fulfilled them automatically. By encouraging/forcing the developer to actually add the call then the implementation is at least complete and self-contained in its own right. I suppose maybe this is why you favoured the hash prefix as it definitely would be compiler magic for these cases, but I think without auto-insertion it isn’t really compiler magic, certainly no more than visibility keywords are.</div></body></html>