objective-c – Cocoa:测试以查找NSString是不可变的还是可变的?

objective-c – Cocoa:测试以查找NSString是不可变的还是可变的?,第1张

概述这会产生一个不可变的字符串对象: NSString* myStringA = @"A"; //CORRECTED FROM: NSMutableString* myStringA = @"A"; 这会产生一个可变的字符串对象: NSMutableString* myStringB = [NSMutableString stringWithString:@"B"]; 但是这两个对象都被报告为同一类 这会产生一个不可变的字符串对象:

Nsstring* myStringA = @"A";  //CORRECTED FROM: NSMutableString* myStringA = @"A";

这会产生一个可变的字符串对象:

NSMutableString* myStringB = [NSMutableString stringWithString:@"B"];

但是这两个对象都被报告为同一类对象“NSCFString”:

NSLog(@"myStringA is type: %@,myStringB is type: %@",[myStringA class],[myStringB class]);

那么什么是内部区分这些对象,以及如何测试它,以便我可以轻松地确定一个神秘的字符串变量是不可变的还是可变的,然后再做一些邪恶的事情呢?

解决方法 这些文档包括一个相当长的解释,说明为什么Apple不希望你这样做以及为什么他们在 Receiving Mutable Objects中明确不支持它.摘要是:

So don’t make a decision on object
mutability based on what introspection
tells you about an object. Treat
objects as mutable or not based on
what you are handed at the API
boundarIEs (that is,based on the
return type). If you need to
unambiguously mark an object as
mutable or immutable when you pass it
to clIEnts,pass that information as a
flag along with the object.

我发现他们的NSVIEw示例最容易理解,它说明了一个基本的Cocoa问题.你有一个名为“elements”的NSMutableArray要作为数组公开,但不希望调用者搞砸.你有几个选择:

>将NSMutableArray公开为NSArray.
>请求时始终制作不可变副本
>将元素存储为NSArray,并在每次变异时创建一个新数组.

我已经在各个方面完成了所有这些工作. #1是迄今为止最简单,最快速的解决方案.它也很危险,因为数组可能会在调用者的背后发生变异.但Apple表示这是他们在某些情况下所做的事情(请注意NSVIEw中的-subviews警告).我可以确认,虽然#2和#3更安全,但它们可能会产生严重的性能问题,这可能就是为什么Apple选择不在像-subvIEws这样经常访问的成员上使用它们的原因.

所有这一切的结果是,如果你使用#1,那么内省就会误导你.你有一个NSMutableArray强制转换为NSArray,并且内省将表明它是可变的(内省无法知道其他情况).但你不能改变它.只有编译时类型检查可以告诉你,所以这是你唯一可以信赖的东西.

对此的修复将是某种可变数据结构的快速写时复制不可变版本.这样#2可能会以良好的性能完成.我可以想象NSArray集群的更改将允许这样做,但它今天在Cocoa中不存在(并且可能在正常情况下影响NSArray性能,使其成为非首发).即使我们拥有它,也可能有太多的代码依赖于当前的行为来允许可信的内省被信任.

总结

以上是内存溢出为你收集整理的objective-c – Cocoa:测试以查找NSString是不可变的还是可变的?全部内容,希望文章能够帮你解决objective-c – Cocoa:测试以查找NSString是不可变的还是可变的?所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/web/1034254.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-24
下一篇 2022-05-24

发表评论

登录后才能评论

评论列表(0条)

保存