<div dir="ltr"><div><span style="font-size:12.800000190734863px">I'm not sure I follow your example. Cat.Animal doesn't make much sense to me while Animal.Cat makes perfect sense.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">import Animal</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">let pet = Cat()</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">When importing HTTP you know you'll deal with HTTP requests and not anything else. And if you do import another module which also has Request (never happened to me) you have to make it clear which one you're referring to. So you'll have to do HTTP.Request, SOAP.Request. So in both scenarios, there won't be any confusion. On the other hand prefixing everything ends up adding noise to the API. </span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">> Your particular setup is sync, right? ;-></span><br></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">It is, but I really don't care about prefixing with Sync, if needed. I honestly find it weird to mark an API Sync since really, most of the APIs are synchronous (in general of course). Is there any async API in Swift's standard library? But again, non-issue for me. I'd be totally ok with Sync.</span></div><div><br></div>> <span style="font-size:12.800000190734863px">For async you usually need some way to hold on to a buffer, and that is DispatchData</span><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Sorry can you elucidate that? If you have the pointer, you're holding the buffer aren't you? I'm not sure I follow the issue.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 May 2017 at 20:09, Helge Heß via swift-server-dev <span dir="ltr"><<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-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"><span class="">On May 27, 2017, at 12:55 AM, Paulo Faria <<a href="mailto:paulo@zewo.io">paulo@zewo.io</a>> wrote:<br>
> Helge! I agree with most of your suggestions and I'll update my proposal with them. There's only one I'm not with you and it's about the HTTP prefix. The example you mentioned could be easily solved by adding `HTTP.` when referring to the specific type.<br>
><br>
> import HTTP<br>
> import SOAP<br>
><br>
> let request = HTTP.Request()<br>
><br>
> We have used Request and Response without prefixes for about two years and not once anyone complained about that. I imagine others who use the same naming scheme can testify to that.<br>
<br>
</span>Having seen such overloading in Java frameworks before I simply disagree with that. The object in question is plainly a HTTPRequest(Head) not just some arbitrary request. The ‘HTTP’ really is part of the thing. In fact the ‘arbitrary’ request could be an NSOperation, providing functionalities such as pause, cancel, etc.<br>
<br>
In a way it is like<br>
<br>
import Cat<br>
<br>
let pet = Animal() // resolving to Cat.Animal()<br>
<br>
But well, if people really like that … ;-) I vote against it.<br>
<span class=""><br>
> About Sync/Async prefix. I was talking about type prefixes not method prefixes. We definitely shouldn't prefix function APIs with sync or async. I honestly don't care too much about which one to use as a default. I just think it makes more sense to prefix the Async ones.<br>
<br>
</span>Your particular setup is sync, right? ;-><br>
<span class=""><br>
> About raw buffers we could provide APIs that take an array of Unsafe[Mutable]<wbr>RawBufferPointer to pass them to readv, writev and company. Those could also be easily converted to DispatchData in the frameworks that prefer to use it.<br>
<br>
</span>This is a little related to sync vs async. For async you usually need some way to hold on to a buffer, and that is DispatchData. For sync you usually don’t have to, and pointers to buffers can be faster.<br>
<br>
Though I do think that sync is more appropriate for many server builders, I think that the goal for Swift-Server would be more oriented towards async. I may be wrong.<br>
<br>
hh<br>
<br>
<br>______________________________<wbr>_________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br>
<br></blockquote></div><br></div>