<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 Feb 26, 2016, at 3:17 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</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 think names like "Daniel Dunbar's String Extensions" is great when talking in English about a specific extension but I think the actual name should be as simple and elegant as possible without overlapping with built-in keywords.</div></div></div></blockquote><div><br class=""></div><div>Yes, indeed, I meant as you think: when talking out loud about things we refer to the package as “Daniel Dunbar’s String Extension”, but in the code we would want:</div><div><br class=""></div><div> import StringExtensions</div><div><br class=""></div><div>or in the case of conflict:</div><div><br class=""></div><div> import ddunbar.StringExtensions</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="font-size: 12px;" class=""><font face="Menlo" class="">import org.sadun.StringUtilities // I can live with this but I'd rather import with a custom name established in dependencies</font></div></div></div></blockquote><br class=""></div><div>Another reason I think to avoid being able to customize the import name is for consistency in the packaging community. We should be trying to establish recognizable names.</div><br class=""></body></html>