Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-8787] type(of:) not returning dynamically-created subclasses #51295

Closed
swift-ci opened this issue Sep 18, 2018 · 3 comments
Closed

[SR-8787] type(of:) not returning dynamically-created subclasses #51295

swift-ci opened this issue Sep 18, 2018 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-8787
Radar None
Original Reporter johnestropia (JIRA User)
Type Bug
Status Resolved
Resolution Won't Do
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug
Assignee None
Priority Medium

md5: c0e5a08424340faee038a65df080116f

Issue Description:

I have a Swift class "CoreStoreManagedObject" which subclasses NSManagedObject. More subclasses of this type are created with "objc_allocateClassPair()", and then some NSObject methods are overrided dynamically using "class_addMethod()", in my particular case, "keyPathsForValuesAffectingValueForKey:".

Until Swift 4.1,

type(of: object).keyPathsForValuesAffectingValueForKey("someKeyPath")

always worked as expected, returning values funneled through the created subclasses. In Swift 4.2, "type(of🙂" seems to return the compile-time class (which returns nothing). I am not sure if this is by design or if I hit a rare edge case.

For now I work around this by writing

func cs_dynamicType<T: AnyObject>(of instance: T) -> T.Type {
    
    return object_getClass(instance) as! T.Type
}

and using it in place of "type(of🙂"

I reproduced this with the Unit tests in the library https://github.com/JohnEstropia/CoreStore

Commit: 40f458a09c0177d15ceab1561acaede2799c4f2d (post-fix)

Replace "cs_dynamicType(of🙂" usage in "DynamicModelTests.swift" back to "type(of🙂" to reproduce Unit Test failure.

@belkadan
Copy link
Contributor

This was a deliberate change in Swift 4.2 to bring type(of🙂 in alignment with -class, which also fixed some important issues where the Swift runtime would look for information that was associated with the original user-defined class rather than the dynamic subclass. Your cs_dynamicType seems reasonable and correct to me for when you actually need the dynamic class type value.

@jckarter, @mikeash, anything to add?

@mikeash
Copy link
Contributor

mikeash commented Sep 18, 2018

I think you've pretty much covered it. Just for some additional context, one major reason for this was to make sure that Bundle(for: type(of: object)) produced the expected result, which it doesn't when type(of: object) returns the magic runtime-allocated subclass when object is the target of KVO.

@swift-ci
Copy link
Collaborator Author

Comment by John Estropia (JIRA)

Thanks for the clarification. I think the the Bundle(for🙂 usage sounds reasonable.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

3 participants