ole / ampere Goto Github PK

public protocol UnitProduct {
    associatedtype Factor1: Dimension
    associatedtype Factor2: Dimension
    associatedtype Product: Dimension

    typealias UnitMapping = (Factor1, Factor2, Product)

    static func defaultUnitMapping() -> UnitMapping
    static func preferredUnitMappings() -> [UnitMapping]
}

This capability is described in SE-0092, which has been implemented a few days ago, but it is not available in Xcode 8 beta 4 yet.

It might make sense to change the directory structure to the one expected by the Swift Package Manager. We could then use swift package generate-xcodeproj to create the Xcode project.

I can’t do this at the moment because:

• SwiftPM only supports macOS and Linux at this point (not iOS).
• The units and measurement APIs require macOS 10.12.
• I haven’t upgraded to macOS 10.12 yet.

This currently produces an error because UnitForce already conforms to UnitProduct for force = mass × acceleration and we cannot add another conformance to the same protocol:

/// Pressure = Force / Area ⇔ Force = Pressure * Area
/// 1 Pa = 1 N / 1 m²
extension UnitForce: UnitProduct {
    public typealias Factor1 = UnitPressure
    public typealias Factor2 = UnitArea
    public typealias Product = UnitForce

    public static func defaultUnitMapping() -> (Factor1, Factor2, Product) {
        return (.newtonsPerMetersSquared, .squareMeters, .newtons)
    }
}

Is it necessary to introduce another protocol (like UnitRatio) for this?

Travis CI?

All meaningful relations between the built-in unit types should be pre-defined here. Users should not be required to add their own for the built-in types.

The bug I reported about inconsistent behavior of XCTest assertions with Measurement values is fixed in Xcode 8 GM, so I can probably remove my custom test assertions.

Thanks @ole for putting your articles code into this library. When reading them through I thought "that would be great as a library for this project" and I've just included it in one of our projects. Builds fine with Carthage, but it would be great to have a tagged version so we don't have to specify the master branch. That would prevent unwanted updates including breaking changes.

Currently we include this in our Cartfile:

github "ole/Ampere" "master"

I'd rather see something like this though (even if it is a 0 major version, it's better than master):

github "ole/Ampere" ~> 1.0

This test fails on Linux:

    func testWithNonBaseUnits() {
        let factor1 = Measurement(value: 100, unit: UnitArea.squareCentimeters)
        let factor2 = Measurement(value: 10, unit: UnitLength.millimeters)
        let actual: Measurement<UnitVolume> = factor1 * factor2
        let expected = Measurement(value: 100, unit: UnitVolume.cubicCentimeters)
        AmpereTest.assertEqual(actual, expected)
    }

XCTAssertEqual failed: ("0.0001 m³") is not equal to ("0.001 m³") - "0.0001 m³" is not equal to "100.0 cm³"

This is due to a bug in swift-corelibs-foundation. Some of the conversion coefficients for UnitVolume are wrong.

My license file has placeholders for year and copyright holders. Fix that.

Using the current version (0.1) I get the following error when trying to build this project with Xcode 8.3 and Swift 3.1:

UnitAreaTests.swift:17:27: Binary operator '/' cannot be applied to operands of type 'Measurement<UnitArea>' and 'Measurement<UnitLength>'

I also wonder why the test classes build when I run the framework with Cmd+B ...

I'd be cool to also add CocoaPods support. I done this implementation myself last month for my library. Just follow this post and this checklist.

4 tests are currently failing on Linux:

...
2019-10-29T00:29:17.9614291Z /__w/Ampere/Ampere/Tests/AmpereTests/UnitAreaTests.swift:18: error: UnitAreaTests.testDivisionWithDefaultUnits : XCTAssertTrue failed - "m" is not the same unit as "m"
...
2019-10-29T00:29:17.9616731Z /__w/Ampere/Ampere/Tests/AmpereTests/UnitAreaTests.swift:10: error: UnitAreaTests.testMultiplicationWithDefaultUnits : XCTAssertTrue failed - "m²" is not the same unit as "m²"
...
2019-10-29T00:29:17.9618076Z /__w/Ampere/Ampere/Tests/AmpereTests/UnitAreaTests.swift:26: error: UnitAreaTests.testMultiplicationWithNonDefaultUnits : XCTAssertTrue failed - "m²" is not the same unit as "m²"
...
2019-10-29T00:29:17.9666816Z /__w/Ampere/Ampere/Tests/AmpereTests/UnitVolumeTests.swift:19: error: UnitVolumeTests.testWithNonBaseUnits : XCTAssertEqual failed: ("0.0001 m³") is not equal to ("0.001 m³") - "0.0001 m³" is not equal to "100.0 cm³"
...

In your first article you state:

Now add one typealias per unit class to get rid of the UnitLength prefix and I really start to like it:

I just searched the code though and couldn't find things like typealias Length = Measurement<UnitLength> in the code. Why is this, wouldn't it make sense to include them in Ampere, too? I'm now adding them manually to my project, but I wonder the rationale behind not adding them. Not to pollute the API? Dunno, seems like they make sense to me. Would be great to have them IMHO. 👍