Cons of using YapDatabasePolicyCopy

[Joel Ekström]

When reading the wiki, there doesn't seem to be any cons of using YapDatabasePolicyCopy (mainly since it falls back to YapDatabasePolicyContain if the object doesn't conform to NSCopying), so one might wonder why that isn't the default?

If I had to guess I'd say the reason is that if you haven't implement copyWithZone: correctly, this could lead to issues. But it would be nice to know if there are any other reasons not to use it?

Thanks!

[Robbie Hanson]

Yup, as you suspected, it has to do with deep vs shallow copies. Which are often a thorn in the side of developers.

The classic case is the nested mutable dictionary:

```

NSMutableDictionary *a = [NSMutableDictionary dictionary];

a[@“oops”] = [NSMutableDictionary dictionary];

NSMutableDictionary *b = [a mutableCopy];

```

Both `a` & `b` are pointing to the same mutable dict for key ‘oops’.

And custom objects have similar problems. So it was just safer to avoid the potential gotchas by default.

But if you’re confident in your object-copying abilities, you can get a little speed boost by using YapDatabasePolicyCopy.

-Robbie Hanson

--
You received this message because you are subscribed to the Google Groups "YapDatabase" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yapdatabase...@googlegroups.com.
To post to this group, send email to yapda...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joel Ekström]

Thanks!

We normally only work with immutable objects, and `return self;` in `copyWithZone:`, so I guess it could be a slight speed boost in two ways - both in that the objects aren't deserialized per connection, but also that there's actually not much copying going on.

I assume immutability mitigates any gotchas with smarter object policies.

[Robbie Hanson]

> I assume immutability mitigates any gotchas with smarter object policies.

Yup. It mitigates most gotchas for sharing in general.

-Robbie Hanson