I have never run into such an issue.&nbsp; Typically classes tend to have the smallest possible basis of methods.&nbsp; I would consider a class with more than about 10 or 15 methods (including superclasses&#39; methods) to indicate poor design.&nbsp; That is just a rough heuristic.<br>
<br>But you&#39;re right, it would be nice if name qualification applied to classes as well, so that we wouldn&#39;t have to worry about it at all.<br><br><div class="gmail_quote">On Thu, Dec 4, 2008 at 4:53 PM, Jason Dusek <span dir="ltr">&lt;<a href="mailto:jason.dusek@gmail.com">jason.dusek@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> &nbsp;What proposals are out there to address the issue of scoping<br>
 &nbsp;class methods? I always feel I must be careful, when exposing<br>
 &nbsp;a class definition that I want clients to be able to extend,<br>
 &nbsp;that I mustn&#39;t step on the namespace with semantically<br>
 &nbsp;appropriate but overly general names (e.g. &#39;run&#39;). It&#39;d be<br>
 &nbsp;nice if class method names were module scoped and could be<br>
 &nbsp;qualified.<br>
<font color="#888888"><br>
--<br>
_jsn<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</font></blockquote></div><br>