[webkit-dev] Terminology for giving up ownership: take, release, move

Geoffrey Garen ggaren at apple.com
Tue Sep 6 11:07:39 PDT 2016


“take” grinds my gears too — though I’ve gotten used to it, more or less.

I read “object.verb()” as a command, “verb”, directed at “object” (or sometimes as a question, “verb?”, directed at “object”). I think most APIs are phrased this way. And if I were Antonin Scalia, I would make the originalist argument that Smalltalk originally defined a method in object-oriented programming as a message to a receiver — not a message about a sender.

> In the context of a container, take() sort of makes sense by parallel to get(). Though get() could be interpreted as either what the caller is doing or what the callee is doing.
> 
> In other words, you could say that in the code below, function something gets an item from the collection. In that sense, take() is a parallel construct. Of course, you could instead say that function something asks collection to get an item. That's what makes take() not make sense. But I am not sure release() makes sense either way, for a collection. It conveys letting go of the item but doesn't seem to convey fetching in the sake way get() or take() do. I don't think move() would be right in this context either.
> 
> function something(Collection& collection, Key& key)
> {
> 	doSomething(collection.get(key))
> }

Though it is possible to read “get” in this context as “I get from collection”, I think it is more natural to read “get” as a command: “collection, get this for me”. Other access verbs on collections, such as “find”, “add”, and “remove”, establish this pattern.

> Given that explanation, I think a possible direction is to rename the smart pointer release() operation to take(). Many of our smart pointers already have a get(). And the idea of taking the underlying value from a smart pointer kind of makes sense, even though it is caller-perspective.

I’ve gotten used to “take", so I won’t call it pure applesauce, but it’s not my preference.

My favorite suggestion so far is “move”. The C++ standard helps make this a good word because it introduces as terms of art std::move and “move” constructors. But perhaps it is bad for a function named “move” not to return an rvalue reference. For example, one might object to “std::move(collection.move(key))”. Why the double move?

My second favorite suggestion is “release”. It matches a term of art in std smart pointers and it’s pretty clear.

My third favorite suggestion is “remove”. For collections, “remove” is just plain clearer. But “remove” is worse for non-collection value types like smart pointers because we “move” values in C++ — we do not “remove” them.

There are some good thesaurus words like cede or doff or discharge but they all lack familiarity as terms of art.

Geoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160906/36985712/attachment.html>


More information about the webkit-dev mailing list