<div dir="ltr"><div><br></div><div><br></div>> <span style="font-size:12.8px">The caveat is have is this: don’t couple the the atomic steps together when incrementally building it up. When the steps aren’t coupled, it’s significantly easier to iteratively make changes to each of the components. It’s also much easier to review and develop additions because you’ve reduced the surface area for the integration points so there is less to consider, and consequently, it’s easier to validate breaking changes.</span><br style="font-size:12.8px">><br style="font-size:12.8px"><span style="font-size:12.8px">> For example, before any meaningful work can be done to support different types of test runners, the work is going to need to done to break the build & run tests coupling. In this way, I think the proposal does a disservice because it’s not laying a good foundation to build on, it’s laying a foundation that we already know needs to be broken up.</span><br style="font-size:12.8px">><br style="font-size:12.8px"><span style="font-size:12.8px">> There’s a difference between “get something done quick” and “get the most minimal viable product” (MVP) out the door. My objection to the proposal is that I don’t see it setting up the MVP.</span><div><br style="font-size:12.8px"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Can't agree with this more. The point of integration between all these tools (and atomic steps) should be as minimal as possible, and so far the proposals that have come through regarding these components of the building and testing project have either felt very heavy-weight or very coupled (for example, to XCTest or similar). As an example: A simple function that can throw an error (and *maybe* returns a simple status of pass/fail?) is probably enough to facilitate the vast majority of testing frameworks, and it *doesn't* come with lots of baggage of protocols and implementation details that we can't assume will be required or even useful for said framework. We should consider what we can leave out instead.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Swift facilitates all sorts of practical wins in code to promote loose coupling in an extremely lightweight way, without having to resort to the relatively heavy OO patterns we see in Java (and, at times, in C#) -- many of which largely exist because the languages didn't have support for closures until recently. As someone who has authored a third-party testing framework (and made it work with the XCode-provided XCTest API, which was a tremendous headache) I would much prefer to see small, atomic, decoupled integration points. The way to do that is omitting details and working at a nice, high level of abstraction.</span></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">So thank you, David, for mentioning this, and I'm 100% in agreement with you.</span></div><div><br></div><div>My biggest concern with this proposal, as it stands, is that it isn't considering what I think are some very important details that will shape the way the build-tool works longer-term. If there's a generic testing protocol provided by the build tool, how do I import my testing framework within Package.swift *before* Package.swift has been able to download all my dependencies? </div><div><br></div><div>Is there a need for a multi-step, multi-file process here?</div><div><br></div><div>I personally would much rather see us focus our discussion on those questions to create a longer-term proposal than continue to debate a proposal that itself admits that it amounts to a temporary solution. Maybe that's worth opening another topic on swift-build-dev for, but for now, I'm made really uncomfortable by the uncertainty left in this proposal as someone who wants to use and/or create third-party testing tools -- this proposal feels very one-size-fits-all, and that really concerns me.</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 8, 2016 at 11:13 AM, David Owens II via swift-build-dev <span dir="ltr"><<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jan 8, 2016, at 6:08 AM, Drew Crawford <<a href="mailto:drew@sealedabstract.com">drew@sealedabstract.com</a>> wrote:<br>
><br>
> <all the good stuff><br>
<br>
I agree with pretty much all you’ve said. The caveat is have is this: don’t couple the the atomic steps together when incrementally building it up. When the steps aren’t coupled, it’s significantly easier to iteratively make changes to each of the components. It’s also much easier to review and develop additions because you’ve reduced the surface area for the integration points so there is less to consider, and consequently, it’s easier to validate breaking changes.<br>
<br>
For example, before any meaningful work can be done to support different types of test runners, the work is going to need to done to break the build & run tests coupling. In this way, I think the proposal does a disservice because it’s not laying a good foundation to build on, it’s laying a foundation that we already know needs to be broken up.<br>
<br>
There’s a difference between “get something done quick” and “get the most minimal viable product” (MVP) out the door. My objection to the proposal is that I don’t see it setting up the MVP.<br>
<br>
-David<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-build-dev mailing list<br>
<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br>
</div></div></blockquote></div><br></div></div>