Re: [webkit-dev] Terminology for giving up ownership: take, release, move
> On Sep 6, 2016, at 6:43 PM, Maciej Stachowiakwrote: > > RefPtr does also have regular release() though. I'm not sure if this is for a > practical reason or just no one has fixed it yet. It’s still around until we finish getting rid of PassRefPtr, that’s all. > A wacky solution, based on your suggestion for releaseImpl, would be to have > a nonNull method which asserts the pointer is not null and then returns a > self reference, so you'd do move(ref.nonNull()). I don’t think we can do that. I don’t know how to change a RefPtr into a Ref& in C++ even though we know the underlying object layout is identical. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
> On Sep 6, 2016, at 5:27 PM, Darin Adlerwrote: > >> On Sep 6, 2016, at 4:48 PM, Maciej Stachowiak wrote: >> >> STL smart pointers have a 0-argument reset for non-returning remove instead, >> and convention seems to be to use swap() or move() for the returning remove >> on a smart pointer. So an alternate possibility would be to use the above >> convention for collections, but make smart pointers have no remove+get >> operation at all. > > Our modern smart pointers follow the standard library convention you mention > above. > > It’s the peculiar cases that need names, such as: > > “assert this RefPtr is non-null to turn it into a Ref&&”, currently named > releaseNonNull RefPtr does also have regular release() though. I'm not sure if this is for a practical reason or just no one has fixed it yet. I am not sure about the non-null case. A wacky solution, based on your suggestion for releaseImpl, would be to have a nonNull method which asserts the pointer is not null and then returns a self reference, so you'd do move(ref.nonNull()). > > “release the RefPtr inside the String”, currently named releaseImpl(), but > another possibility would be to have impl() be RefPtr& instead of > a StringImpl*, so you could do move(string.impl()) instead of > string.releaseImpl(). That seems pretty reasonable. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
> On Sep 6, 2016, at 4:48 PM, Maciej Stachowiakwrote: > > STL smart pointers have a 0-argument reset for non-returning remove instead, > and convention seems to be to use swap() or move() for the returning remove > on a smart pointer. So an alternate possibility would be to use the above > convention for collections, but make smart pointers have no remove+get > operation at all. Our modern smart pointers follow the standard library convention you mention above. It’s the peculiar cases that need names, such as: “assert this RefPtr is non-null to turn it into a Ref&&”, currently named releaseNonNull “release the RefPtr inside the String”, currently named releaseImpl(), but another possibility would be to have impl() be RefPtr& instead of a StringImpl*, so you could do move(string.impl()) instead of string.releaseImpl(). — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
I thought about why release() seems subtly wrong to me for collections, but not for smart pointers. Specifically, release() puts the focus on giving up ownership, but the in the case of a collection, the most important thing is removal from the collection, where giving up ownership is a detail of the removal. In particular, it doesn't leave a hole, like swap() on spot in the collection with a default-constructed value would, or like release() on a smart does. For this reason, I think move() is also wrong in the collection case). For similar reasons, having a zero-argument remove() on a smart pointer would read a little weird. Sure, you can think of a smart pointer as a collection of one item, but our actual smart pointers either have clear() or no non-returning removal operation. Therefore I wonder if consistency between smart pointers and collections is really the most important factor. Smart pointers and collections are different enough that their operations don't have to be named the same. That said, I do have a proposal that I think is semantically OK for both smart pointers and collections, and also has the correct subject in all cases. Non-removing | accessor | remove-only | remove+get ---|---|- get() |erase()| remove() This has the additional advantage of somewhat more consistency with std:: containers, which name the plain removal operation erase() rather than remove(). A downside is that anyone used to remove() may call it when erase() would do, possibly resulting in slightly less efficient code. STL smart pointers have a 0-argument reset for non-returning remove instead, and convention seems to be to use swap() or move() for the returning remove on a smart pointer. So an alternate possibility would be to use the above convention for collections, but make smart pointers have no remove+get operation at all. For comparison, here is the status quo: Non-removing | Smart pointer | Smart pointer | Container | Container accessor | remove-only | remove+get| remove-only | remove+get ---|---|---|-|- get() |N/A or clear() | release()| remove() | take() > On Sep 6, 2016, at 11:07 AM, Geoffrey Garenwrote: > > “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
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
On Tue, 2016-09-06 at 11:12 -0700, Filip Pizlo wrote: > 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. I agree that move() would be quite confusing; I think we should avoid this option. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
I think “take" is a fine word to indicate that you are taking a value from a HashSet, just like “add" indicates you are adding to the set and remove indicates you are “removing" from the set. It’s true that in all these cases the caller is doing the thing, not the object, but it makes sense in my mind. An alternative would be to change set.add(value) to a static function HashSet::add(set, value), set.remove(value) to HashSet::remove(set, value), and set.take(value) to HashSet::take(set, value), etc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
> On Sep 6, 2016, at 11:07 AM, Geoffrey Garenwrote: > > “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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
“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
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
On Tue, Sep 6, 2016 at 4:29 AM, Daniel Olegovich Lazarenko < dani...@opera.com> wrote: .. > * "take" - a typical name for collections like a blocking queue, heap and > some others (usually ordered). If it's a collection's method, it's > logically expected to return an item. The key distinction between > fred.takeCandy() and say bowl.takeCandy() is that bowl is passive. > That doesn't make sense to me. Why would the object "bowl" be passive, but not "fred"? We treat bowl as a passive bag of data, and expect others to take from it. > I see. Like an actual bowl in the real world? > It's pretty easy to understand and remember, it makes intention more clear > than say "bowl.removeCandy()". > Not to me. When I read or write object-oriented code, I think of it as sending messages of what I want done to the object. I see the object as being an intermediator performing actions on behalf of the caller. Containers and collections are classes that group a set of functions the caller needs done, so it's more convenient to view them as being a mediator, if you will, for the caller. I think trying to map real-world behaviors into object interfaces is trying too hard to mirror the real world. I see it as imposing additional cognitive load on comprehension by requiring me to remember if it's passive or not. In fact, if it's passive that would violate the OOP and real-world paradigms: why would I be sending it a message? Especially in this day and age of smart appliances and IoT I think it's more consistent to think of the bowl as a "smart" bowl that responds to my messages. "Give me all the green candy", "sort candy by size", etc. > Pure OOP style is always the right way when it comes to readability. A > good example mentioned by Stroustrup once that it should be sqrt(5), not > 5.sqrt(). > Do you have a link for that? The closest thing I see to that example ( https://isocpp.org/blog/2014/12/myths-2) is demonstrating the exact opposite, that a non-OOP solution provides better performance by eliminating the dereferencing of a pointer. > Naming is fun. > Learning how to communicate across cultures of all types is fun. ;-) -- Alfonso Guerra Founder/CEO Apokalypse Software Corp. (626) 667-4285 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
On Mon, 2016-09-05 at 10:23 -0700, Filip Pizlo wrote: > The use of "take" for these methods grinds my gears, for the same > reason you were distracted: "take" describes the desires of the > caller, but that doesn't work for me because I read > "fred.makeCoffee()" as "makeCoffee()" being an imperative verb phrase > and "fred" as being the subject that will make me the coffee. So, > "HashMap::take" means to me that the HashMap is taking something from > me, rather than releasing something to me. > > I wonder if there is anyone who is surprised more by release than by > take, and who would find it strange to say > ExceptionOr::releaseReturnValue. I'm more used to seeing "release" used with smart pointers and "take" used with data structures, but I like your argument that the semantics of "take" are backwards. "Release" is clear in either case. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
Hello, For a WebKit observer like me: * "release" - has a well-known meaning in Mac/Objective-C world. It's expected to "free" the memory. Same as COM's IUnknown::Release, but different from auto_ptr::release or unique_ptr::release (which don't free the memory). * "move" - has a well-known meaning in C++ 11 world. Different from "release" above. If I see methods "move" and "release" and they do the same, I will have to learn and understand that trick. * "take" - a typical name for collections like a blocking queue, heap and some others (usually ordered). If it's a collection's method, it's logically expected to return an item. The key distinction between fred.takeCandy() and say bowl.takeCandy() is that bowl is passive. We treat bowl as a passive bag of data, and expect others to take from it. It's pretty easy to understand and remember, it makes intention more clear than say "bowl.removeCandy()". Pure OOP style is always the right way when it comes to readability. A good example mentioned by Stroustrup once that it should be sqrt(5), not 5.sqrt(). Maybe "bowl.takeCandy" is a good compromise to keep it as a method (instead of a global "TakeCandyFromBowl(bowl)"). Naming is fun. -- Daniel https://twitter.com/battlmonstr On Mon, Sep 5, 2016 at 9:00 PM,wrote: > Send webkit-dev mailing list submissions to > webkit-dev@lists.webkit.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.webkit.org/mailman/listinfo/webkit-dev > or, via email, send a message with subject or body 'help' to > webkit-dev-requ...@lists.webkit.org > > You can reach the person managing the list at > webkit-dev-ow...@lists.webkit.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of webkit-dev digest..." > > > Today's Topics: > >1. Terminology for giving up ownership: take, release, move > (Darin Adler) >2. Re: Terminology for giving up ownership: take, release, move > (Filip Pizlo) > > > -- > > Message: 1 > Date: Mon, 05 Sep 2016 10:13:28 -0700 > From: Darin Adler > To: WebKit Development Mailing List > Subject: [webkit-dev] Terminology for giving up ownership: take, > release,move > Message-ID: <3ad4bd53-7cc2-4f26-8d3d-b3631413b...@apple.com> > Content-Type: text/plain; charset=utf-8 > > Hi folks. > > WebKit has some critical functions that involve asking an object to give > up ownership of something so the caller can take ownership. > > In the C++ standard library itself, this is called move, as in std::move. > > In WebKit smart pointers, we call this operation release, as in > RefPtr::releaseNonNull and String::releaseImpl. > > In WebKit collections, we call this operation take, as in HashMap::take > and ExceptionOr::takeReturnValue. > > The release vs. take terminology is distracting to my eyes. The verb > ?take" states what the caller wishes to do, and the verb ?release? states > what the caller wants the collection or smart pointer to do. My first > thought was be to rename the take functions to use the word release > instead, but I fear it might make them harder to understand instead of > easier and clearly it would make them longer. > > Does anyone have other ideas on how to collapse WebKit project terminology > down so we don?t have three different single words that are used to mean > almost the same thing? > > ? Darin > > -- > > Message: 2 > Date: Mon, 05 Sep 2016 10:23:35 -0700 > From: Filip Pizlo > To: Darin Adler > Cc: WebKit Development > Subject: Re: [webkit-dev] Terminology for giving up ownership: take, > release, move > Message-ID: <8c068bfc-10d2-4388-919a-761ca9323...@apple.com> > Content-Type: text/plain; charset=utf-8 > > > > On Sep 5, 2016, at 10:13 AM, Darin Adler wrote: > > > > Hi folks. > > > > WebKit has some critical functions that involve asking an object to give > up ownership of something so the caller can take ownership. > > > > In the C++ standard library itself, this is called move, as in std::move. > > > > In WebKit smart pointers, we call this operation release, as in > RefPtr::releaseNonNull and String::releaseImpl. > > > > In WebKit collections, we call this operation take, as in HashMap::take > and ExceptionOr::takeReturnValue. > > > > The release vs. take terminology is distracting to my eyes. The verb > ?take" states what the caller wishes to do, and the verb ?release? states > what the caller wants the collection or smart pointer to do. My first > thought was be to rename the take functions to use the word release > instead, but I fear it might make them harder to understand instead of > easier and clearly it would make them longer. > > > > Does anyone have other ideas on how