On Wed, Aug 27, 2008 at 6:59 PM, R.L. Grigg <[EMAIL PROTECTED]> wrote: > Hmm, I guess the wrinkle in this particular case is if the "contract" doesnt > specify something that the programmer assumes to be safe to do (like > enumerating backwards), how can you know how to implement your end? I guess > there are times when the underlying implementation details can/must > influence your highlevel design?
When at all possible, your code should only be influenced by underlying implementation details in the realm of performance, not correctness. This business of copying the array is a good example. It's fine to write code that depends on the array no longer being copied, so long as it still performs acceptably (although potentially worse) if the array is copied. There are a lot of cases where you have to make assumptions about which technique is fastest, and this in turn depends on how those techniques are implemented at a low level. But so long as your code merely becomes slower when the assumptions change, but still functions, this is generally not a problem. In the case of enumerating backwards, the documentation says a lot about how you should never mutate collections that you're enumerating and nothing about it being safe to mutate while enumerating backwards. The conclusion there should be obvious. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
