<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="">Yup!<div class=""><br class=""></div><div class="">&nbsp;- Daniel</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 29, 2016, at 8:53 AM, Erica Sadun &lt;<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>&gt; 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'll try writing up a proposal. Does everything work the same for swift-build-dev as -evolution?</div><div class=""><br class=""></div><div class="">-- E</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 26, 2016, at 5:04 PM, Max Howell &lt;<a href="mailto:max.howell@apple.com" class="">max.howell@apple.com</a>&gt; 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 26, 2016, at 3:17 PM, Erica Sadun &lt;<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>&gt; 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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">&nbsp; &nbsp; import StringExtensions</div><div class=""><br class=""></div><div class="">or in the case of conflict:</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; 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 class="">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=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>