[Webkit-unassigned] [Bug 22479] Consider renaming to 'deepCopy' the 'copy' methods that perform a deep copy

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 25 14:07:15 PST 2008


https://bugs.webkit.org/show_bug.cgi?id=22479





------- Comment #5 from ap at webkit.org  2008-11-25 14:07 PDT -------
(In reply to comment #4)
> Why do you think the comment is misleading? Because the reference count doesn't
> get copied?

I think I was a bit too quick to criticize the comment.

Maybe I'm just confused trying to understand why copy() is bad - shallow copy
is the default one, so a method named copy() should be expected to do something
different, shouldn't it?

> If the sole purpose of these functions is to move objects across threads, and
> they should optimize to copy ThreadSafeShared data in a shallow way, then a
> name like "threadSafeCopy" would be better. What do you think of that?

That seems to be rather wordy, especially for the just added
String::substringCopy(). Worse, it doesn't add much clarity, as it doesn't
describe what is thread safe (it sounds like it is the copy operation itself).
And "thread safe" is a very bloated term.

Copying objects across threads is the only reason, but not the only use case -
the same function needs to be used when getting/setting values in global
objects, such as caches, where names that talk about threads (like
"detachFromThread()") would be confusing, too.

The best I can think of is "copyOut()" - it's somewhat mysterious, but concise,
and close to the meaning that it has in kernel programming. But we won't have a
matching "copyIn()". Or maybe we could just keep "copy()".


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list