You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Classes like _StringStorage and _DictionaryStorage are private details of the standard library, and can (I'm making a PR shortly) have KVO subclassing disabled at runtime safely, but we jump through slow hoops to support the possibility that they might be (see swift_getObjectType and swift_getObjCClassFromObject in SwiftObject.mm). If we could put a flag on the metadata that indicates that we guarantee it's safe to skip the hoop jumping, we could speed up some things.
I've worked around this for String bridging by adding a stub that calls object_getClass, but it would be neat to a) not have to work around this, and b) take advantage of the fact that _swift_getClass knows how to do direct isa access where supported.
The text was updated successfully, but these errors were encountered:
Additional Detail from JIRA
md5: 2c87dbccb5c814733a7fb36549d7dc6f
Issue Description:
Classes like _StringStorage and _DictionaryStorage are private details of the standard library, and can (I'm making a PR shortly) have KVO subclassing disabled at runtime safely, but we jump through slow hoops to support the possibility that they might be (see swift_getObjectType and swift_getObjCClassFromObject in SwiftObject.mm). If we could put a flag on the metadata that indicates that we guarantee it's safe to skip the hoop jumping, we could speed up some things.
I've worked around this for String bridging by adding a stub that calls object_getClass, but it would be neat to a) not have to work around this, and b) take advantage of the fact that _swift_getClass knows how to do direct isa access where supported.
The text was updated successfully, but these errors were encountered: