> On Sep 6, 2016, at 11:07 AM, Geoffrey Garen <[email protected]> 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
> [email protected]
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev
