Support Actor Protocol about mockolo HOT 6 OPEN

I hope this feature exists in this OSS! I see three ways to support this:

1. Add an annotation specifying the object nominal types of the mock
2. Mocks for that protocol that conform to the Actor automatically become actor
3. Mocks for that protocol that conform to the another protocol conforming Actor automatically become actor

// 1.
/// @mockable(object: actor)
protocol Hoge: Actor {
    var count: Int { get }
}

///
/// @Generated by Mockolo
///
actor HogeMock: Hoge {
    init() { }
    init(count: Int = 0) {
        self.count = count
    }

    private(set) var countSetCallCount = 0
    var count: Int = 0 { didSet { countSetCallCount += 1 } }
}

// 2.
/// @mockable
protocol Hoge: Actor {
    var count: Int { get }
}

///
/// @Generated by Mockolo
///
actor HogeMock: Hoge {
    init() { }
    init(count: Int = 0) {
        self.count = count
    }

    private(set) var countSetCallCount = 0
    var count: Int = 0 { didSet { countSetCallCount += 1 } }
}

// 3.
/// @mockable
protocol Hoge: Fuga {
    var count: Int { get }
}
protocol Fuga: Actor {
}

///
/// @Generated by Mockolo
///
actor HogeMock: Hoge {
    init() { }
    init(count: Int = 0) {
        self.count = count
    }

    private(set) var countSetCallCount = 0
    var count: Int = 0 { didSet { countSetCallCount += 1 } }
}

I implemented the changes that fulfill "1." and "2." above in my forked branch: master...treastrain:c20f64b140c78b9f05202e661a07c43c15834358 (No test has been added to this yet now.)

However, I have yet to come up with a way to achieve "3." Any suggestions?

from mockolo.

Thanks for the Issue!
I'm waiting for the PR🥺

from mockolo.

@treastrain

I agree with "2." since only actor can conform to the Actor protocol.

I see. I will create a pull request for this part in my spare time.

Thanks, waiting for PR 🙏

"1." may cause mock build errors when marking protocols that are not Actor.

The same could be said here for the already existing annotations typealias, rx, combine, etc. It is the responsibility of the person making this statement, and we do not believe that we should be concerned about mock build errors when marking protocols that are not Actor.

Since you are right, it seems that if "3." cannot be realized by any means, "1." may be adopted.
As for how to realize "3.", the is operator is just an example, and I also thought it could not be solved 😭

from mockolo.

@treastrain Thanks for the suggestion!

I agree with "2." since only actor can conform to the Actor protocol.
Couldn't "3." be achieved using SwiftSyntax and the is operator?
"1." may cause mock build errors when marking protocols that are not Actor.
It seems like it would be better to support only "2." (and "3." if possible) first, what do you think?

from mockolo.

@uhooi

Thanks for your response!

The diffs shown in master...treastrain:c20f64b140c78b9f05202e661a07c43c15834358 are a mixture of "1." and "2." but the implementation effort is light < "1." < "2." < heavy.

I agree with "2." since only actor can conform to the Actor protocol.

I see. I will create a pull request for this part in my spare time.

"1." may cause mock build errors when marking protocols that are not Actor.

The same could be said here for the already existing annotations typealias, rx, combine, etc. It is the responsibility of the person making this statement, and we do not believe that we should be concerned about mock build errors when marking protocols that are not Actor.

Couldn't "3." be achieved using SwiftSyntax and the is operator?

My knowledge of SwiftSyntax is lacking, so a solution using it is not immediately obvious.
But as for the is operator, I understand that when this library generates a mock, it does not build and import the source code for the mock generation target, so it can't handle that object directly, so I don't think I can solve it that way.

from mockolo.

Thank you! let me say one opinion from my side. 🙏
I prefer option 1 because we can't take care of @globalActor if we adopt option 2. (if it is not correct please teach me.)
Besides that, option 1 is more flexible and independent on certain swift future change.

oh I am sorry. I found globalActor protocol should be mocked with class.

Besides that, option 1 is more flexible and independent on certain swift future change.

one of example is typealias and AnyActor, DistributedActor.

from mockolo.