<div dir="ltr">On Fri, Dec 4, 2015 at 4:44 PM, David Waite <span dir="ltr">&lt;<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>&gt;</span> wrote:<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>All of the matching methods (such as equal, contains, raiseError, raiseException) are also module functions, so you would likely just pull them all in. The Hamcrest Java project is very similar to Nimble, and they have a utility class generator (static methods calling other class static methods) specifically for reducing the number of static imports you have to put at the top of your test files.</div></div></div></blockquote><div><br></div><div>They don&#39;t need to be, though. Protocol extensions offer an improved way of handling this. I put together a proof-of-concept PR a short while ago:</div><div><br></div><div><a href="https://github.com/Quick/Nimble/pull/218">https://github.com/Quick/Nimble/pull/218</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Ruby has it as well, and while it perhaps a bit more ‘magic’ than some would desire, you will not find Ruby developers lamenting its existence. Javascript’s inconsistent historical behaviors greatly contribute to the perception that rebinding is a design flaw.</div></div></div></blockquote><div><br></div><div>The Ruby community in the past has been somewhat divided on the use of instance_eval/exec vs. yielding block arguments for clarity, though there are many popular DSL-like libraries that take advantage of instance_eval/exec and are expressive and easy to read at the cost of opaqueness.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>However, the behavior I’m describing is different than either Ruby or Javascript:<br></div><div>- both Ruby and Javascript are late bound, which allows the JIT implementations to adapt to whatever type instance is given. Swift is not a late bound language, so it must know the types it is working with beforehand</div><div>...</div></div></div></blockquote><div><br></div><div>Perhaps a bracketed annotation could assign an unbound type to a closure:</div><div><br></div><div>    let builder: [MyType] () -&gt; Void = { ... }</div><div>    builder.bind(instance)() // or builder[instance](), or some other syntax</div><div><br></div><div>I agree that such a mechanism would allow for very expressive, type-safe APIs. IDEs could take the guesswork out of &quot;what is &#39;self&#39;?&quot;. At the same time, I understand apprehensions and aversions to both the complexity and ambiguities associated with such a feature, and they may go against Swift&#39;s principles at the moment.</div></div></div></div>