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

[Filip Pizlo]

> On Sep 6, 2016, at 11:07 AM, Geoffrey Garen <ggaren at apple.com> wrote:
> 
> “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?

But it kinda does return an rvalue reference!  If foo() returns T then:

	bar(foo())

will bind to the && overload of bar().  I don't think you'd have to do std::move(collection.move(key)).

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

FWIW, I still like release() better than move().  a = move(b) is a command to the system to move b to a.  So, value = collection.move(key) feels like a command to the collection to move key to value, which is clearly not what is going on.

-Filip


> 
> 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
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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