<div dir="ltr">On Sun, Oct 15, 2017 at 12:56 AM, Adam Kemp <span dir="ltr"><<a href="mailto:adam.kemp@apple.com" target="_blank">adam.kemp@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> On Oct 14, 2017, at 10:32 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> Therefore, it is entirely OK (to me) if the result is something that is so obtuse as to be at first meaningless to most people.<br>
<br>
</span>I can’t speak for others, but it’s not ok with me. API is UX. It should be understandable and approachable. If this were a function that was considered dangerous and we wanted to discourage its use then maybe I could buy this argument, but I don’t think that’s quite the case here. Even if you don’t think it’s the best API to use or the most common it should still be named clearly. </blockquote></div><br></div><div class="gmail_extra">I don't disagree with you that it should be _clear_. I'm simply wondering out loud whether it is possible to name this method _intuitively_ (i.e., clear without resorting to documentation) given that it lives in the nexus of an inherent contradiction between protocol and implementing type which is anything but intuitive (or even clear after you read the documentation).</div><div class="gmail_extra"><br></div><div class="gmail_extra">If it is not possible to name this method _intuitively_, then it is not possible to name it _well_. Then, given the option between obtuse-but-correct and approachable-but-misleading, I would opt for the former as the _least bad_ option.</div></div>