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

Reply via email to