Closed igorsales closed 8 years ago
Trying to understand the code. Could you explain this unusual direct reference to the ivar in MKTClassObjectMock.m?
//if (swizzle.mockedClass == self.mockedClass) {
// At time of dealloc, it's possible the weak ref to swizzle.mock is nil,
// so we also check directly on the struct member
if (swizzle.mock == self) || swizzle->_mock == self) {
Or maybe I should ask, how did you discover the need for this?
When I was developing it, the body of the if wasn’t being called, so I investigated why, and the problem is that sometimes (under a dealloc call) when that block is called, the ivar accessor (swizzle.mock) returns nil, but the ivar is still there.
Strange yeah, I didn’t expect it to work that way. I think it might have to do with compiler optimizations. When running in debugging, I think it would almost always go into the block, while during Unit Testing and production it wouldn’t.
I hope this helps, —i
On Jun 27, 2016, at 1:00 AM, Jon Reid notifications@github.com wrote:
Trying to understand the code. Could you explain this unusual direct reference to the ivar in MKTClassObjectMock.m?
//if (swizzle.mockedClass == self.mockedClass) { // At time of dealloc, it's possible the weak ref to swizzle.mock is nil, // so we also check directly on the struct member if (swizzle.mock == self) || swizzle->_mock == self) {
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jonreid/OCMockito/pull/128#issuecomment-228654444, or mute the thread https://github.com/notifications/unsubscribe/AACXZQ5F6NEeVd8Gg1N0DHk0HpS1Gsdqks5qP1kCgaJpZM4IdJ51.
--i
e-mail: self@igorsales.ca twitter: @igorsales blog: https://blog.igorsales.ca web: https://igorsales.ca
Thanks again for "getting the ball rolling"! The significant changes I made were:
stopMocking
support.stubSingleton()
with incorrect argumentsI'll start preparing a release.
Cool, thanks so much for accepting it!
Cheers, —i
On Sep 4, 2016, at 8:22 PM, Jon Reid notifications@github.com wrote:
Thanks again for "getting the ball rolling"! The significant changes I made were:
Did "extract class" to pull out MKTSingletonSwizzler Added error reporting if you provide stubSingleton() with incorrect arguments I'll start preparing a release.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jonreid/OCMockito/pull/128#issuecomment-244637143, or mute the thread https://github.com/notifications/unsubscribe-auth/AACXZUuu6God-qKlYaaiFPpMpLSl3m1Qks5qm2C2gaJpZM4IdJ51.
--i
e-mail: self@igorsales.ca twitter: @igorsales blog: https://blog.igorsales.ca web: https://igorsales.ca
A patch for the rest of us, who know it's easier to live with the reality that singletons are here to stay. While adding the ability to set those objects as properties, sometimes, it just makes sense to plainly use them. I hope this patch is good enough to get the ball rolling.