Re: [swift-corelibs-dev] [swift-evolution] Proposal: Conforming NSDate to Comparable

[Stephen Celis via swift-corelibs-dev]

Seems to me that anything with `-compare:` could conform to Comparable. The 
list, however, is surprisingly short, and half bridge over to native Swift 
types that are already Comparable:

- [NSDate compare:]
- [NSIndexPath compare:]
- [NSNumber compare:]
- [NSString compare:]

Looks like NSIndexPath may be the only other contender.

Stephen

> On Dec 6, 2015, at 11:47 AM, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi Chris,
> 
> Thanks for bringing this idea to the list.
> 
> Is NSDate really the only thing that we want to conform to comparable, or is 
> there a set of classes which should do so? I’d like to think about the larger 
> set of consequences here (and if possible, deal with one coherent answer for 
> all of Foundation rather than do these classes one at a time).
> 
> - Tony
> 
>> On Dec 5, 2015, at 3:36 PM, Chris Amanse via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hello Swift Developers,
>> 
>> I think it's a good idea to conform NSDate to the Comparable protocol, so 
>> instead of using:
>> 
>> if someDate.compare(today) == .OrderedAscending { }
>> 
>> Developers can easily compare using compare dates using comparison operators:
>> 
>> if someDate < today { }
>> 
>> In my opinion, the code is still readable if developers use comparison 
>> operators on NSDates.
>> 
>> Here's a quick implementation from my swift-corelibs-foundation fork: 
>> https://github.com/chrisamanse/swift-corelibs-foundation/commit/3c4eff643c5271de5bec2461798051347be13916
>>  
>> 
>> 
>> Thank you.
>>  ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> 
> 
>  ___
> swift-evolution mailing list
> swift-evolut...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Stephen Celis via swift-corelibs-dev]

Brandon Williams and I have come across a lot of inconsistencies between 
Foundations in our Swift web work. We’ve been trying to file bugs when we 
remember to, but I’m curious if there’s a better way to catch these. Is the 
Foundation test suite run against both implementations to attempt to catch 
these kinds of things? If not it would seem like a big win to do so. If so, I 
suppose we could help by beefing up the test coverage?

Stephen

> On Nov 16, 2017, at 12:18 PM, Ian Partridge via swift-corelibs-dev 
>  wrote:
> 
> Hi, it looks like Foundation on Darwin capitalises certain HTTP
> methods but not others:
> 
> ```
> let methods = ["get", "head", "post", "put", "delete", "connect",
> "options", "trace", "patch"]
> 
> var x = URLRequest(url: URL(string: "/hello")!)
> 
> for m in methods {
>x.httpMethod = m
>print(x.httpMethod!)
> }
> ```
> 
> Output on Darwin:
> GET
> HEAD
> POST
> PUT
> DELETE
> CONNECT
> options
> trace
> patch
> 
> Currently on Linux we don't do any capitalization so I'd like to fix this.
> 
> Is my list of 6 methods above the definitive list of which HTTP
> methods should be capitalized?
> 
> Thanks,
> 
> -- 
> Ian Partridge
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Stephen Celis via swift-corelibs-dev]

> On Nov 16, 2017, at 2:02 PM, Alex Blewitt  wrote:
> 
> There is a TestFoundation target in the swift-corelibs-foundation project, 
> which can allow the tests to be run against the open source codebase.

Sorry, maybe I wasn’t clear, I was wondering if there’s a test suite that 
regularly runs against _both_ the open-source Foundation implementation _and_ 
the closed-source Foundation implementation in order to catch inconsistencies 
across code bases.

> Note that there's no requirement for the methods to be capitalised in 
> URLRequest. Chances are that the implementation is such that there are some 
> pre-defined values which can be used/replaced for keys, but other ones will 
> take the case of whatever you put in them.
> 
> I also don't think it makes sense to capitalise everything because in most 
> cases it will have no effect, but is wasted computation. So in other words, 
> don't pass lowercase values into the x.httpMethod if you don't want it.


I don’t have a strong enough opinion to argue for or against auto-capitalizing 
the HTTP method, but I _do_ care for consistency across platforms. We have a 
significant test suite in our code bases with a lot of unit tests and snapshot 
tests that pass on our dev machines (Mac), but fail on Linux.

Stephen
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Stephen Celis via swift-corelibs-dev]

> On Nov 16, 2017, at 2:57 PM, Alex Blewitt  wrote:
> 
> I understood your question, but I can only point to you as to what is 
> available and run on the swift-corelibs-foundation open source project.

Sorry to continue on this train (especially since it’s a big of a derailment). 
I’m really not trying to be obtuse, but I don’t understand your answer. I was 
asking what I thought were simple yes/no questions that didn’t require any 
private/confidential information about the closed source code. Do you or does 
anyone else know if the open-source project has a test target that runs its 
test suite against the closed-source implementation? If not, shouldn’t it?

I read your first response as: swift-corelibs-foundation has a test suite that 
runs against its own implementation. Am I missing something?

> Yes, being consistent between platforms is one of the purposes of the 
> swift-corelibs-foundation project. However, there are both run-time and 
> implementation differences between the two platforms; the existence (or not) 
> of the Objective-C runtime, whether or not comparisons are performed using 
> the rules based on the Darwin version of Foundation or the ICU rules on the 
> open-source version of Foundation, and so on.

I understand this, but I’m not talking about run-time/implementation 
differences, just testable input/output expectations on the functions and 
methods that swift-corelibs-foundation can implement. Assuming that the 
functions and methods swift-corelibs-foundation can implement should behave the 
same, its test suite should be able to run against Darwin Foundation.

> Some of the differences are just bugs, in which case we can try and resolve 
> the issues when they're filed at bugs.swift.org  or 
> via pull requests on the GitHub repository. Some of the issues are ones where 
> the implementation in the open source version is missing; either because the 
> functionally cannot be implemented (e.g. dynamic unloading of bundles) or 
> because it's not been prioritised yet (e.g. 
> https://github.com/apple/swift-corelibs-foundation/search?utf8=✓&q=nsunimplemented
>  
> ).
>  In particular the big items that are missing at the moment are 
> encoder/decoder implementations and those relating to nspredicate/expression, 
> which both can be implemented in runtimes that have dynamic introspection of 
> data structures but which therefore can't be implemented in Linux.
> 
> Having said that, if you do find consistency issues which are important to 
> you then please file bugs, and optionally provide pull requests for them. We 
> can help on the mailing list to try and resolve any issues or questions as 
> they arise.

I totally have been and will continue to! I was hopeful that we could discuss a 
system that automates some of this and can catch regressions and 
inconsistencies more quickly. Is there any reason not to discuss such a 
solution?

Stephen___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Stephen Celis via swift-corelibs-dev]

> On Nov 16, 2017, at 3:30 PM, Ian Partridge  wrote:
> 
>> Is the Foundation test suite run against both implementations to attempt to 
>> catch these kinds of things?
>> If not it would seem like a big win to do so.
> 
> Not yet, but there is work underway to do this.  See
> https://github.com/apple/swift-corelibs-foundation/pull/1286 which
> adds an Xcode project to enable just that.  The goal is to get this
> into CI so that we automatically run the SCLF testsuite against both
> implementations.

Fantastic! That’s the information I was looking for, thanks!

Stephen
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev