
<html><body><div id="edo-message"><div><span style="-webkit-tap-highlight-color: transparent; -webkit-text-size-adjust: auto;"><i>As an alternative to having `open` as a separate access level, we could instead have it merely imply `public`: the canonical form would be `public open`, but source code could just say `open`. Generated interfaces would always say `public open`, so searching for `public` in those would work as you want it to.</i></span></div><div><span style="-webkit-tap-highlight-color: transparent; -webkit-text-size-adjust: auto;"><i><br></i></span></div><div><span style="-webkit-tap-highlight-color: transparent; -webkit-text-size-adjust: auto;"><i><br></i></span></div><div><span style="-webkit-text-size-adjust: auto;">I would not support this. Open and public are orthogonal concepts, just like final and public are today.</span></div><div><span style="-webkit-text-size-adjust: auto;"><br></span></div><div><span style="-webkit-text-size-adjust: auto;">Just because your internal implementation details involve classes and subclasses, you shouldn't have to expose that to the whole world.</span></div><div><span style="-webkit-text-size-adjust: auto;"><br></span></div><div><span style="-webkit-text-size-adjust: auto;">I think it should be an attribute/qualifier on the access level (similar to mutability for properties). You may wish to allow internal subclassing while preventing external subclassing (e.g. The API isn't stable yet, you're thinking of opening it publicly later but you want to refine it through internal usage first).</span></div><div><span style="-webkit-text-size-adjust: auto;"><br></span></div><div><span style="-webkit-text-size-adjust: auto;">Or, as I mentioned before, perhaps you are forced to return an "abstract" class because we don't have sealed protocols.</span></div><div><span style="-webkit-text-size-adjust: auto;"><br></span></div><div><span style="-webkit-text-size-adjust: auto;">These are all decisions for the API author, and by having the openness scopes to access level we give them ultimate flexibility to annotate which parts of their API can be replaced and by whom.</span></div><div><span style="-webkit-text-size-adjust: auto;"><br></span></div><div><span style="-webkit-text-size-adjust: auto;">Karl</span></div></div><div id="edo-original"><blockquote type="cite" style="margin:1ex 0 0 0;border-left:1px #ccc solid;padding-left:0.5ex;"><div><pre><br><br></pre></div></blockquote></div></body></html>