I don’t think adding a prefix will add too much noise to the API, and if
it does it cost less than resolving namespace collision.
It is true that user can use HTTP.Request and SOAP.Request to make it
clean which one ppl is referring to, but it also make code hard to debug
once anyone has accidentally forgot to add the “HTTP.” preflx, and this is
kind of error that the compiler cannot catch sometimes, especially when
they have members and methods used in the function body with the same name
and type (which for a req/res this should be pretty common).
I honestly never seen it happen. Vapor is one of the most popular
frameworks and they also use Request and Response. I'd love to see
real-life reports of issues regarding this matter.
···
On 26 May 2017 at 20:59, Michael Chiu <hatsuneyuji@icloud.com> wrote:
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.I don’t think adding a prefix will add too much noise to the API, and if
it does it cost less than resolving namespace collision.
It is true that user can use HTTP.Request and SOAP.Request to make it
clean which one ppl is referring to, but it also make code hard to debug
once anyone has accidentally forgot to add the “HTTP.” preflx, and this is
kind of error that the compiler cannot catch sometimes, especially when
they have members and methods used in the function body with the same name
and type (which for a req/res this should be pretty common).Michael