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

[Darin Adler]

> On Sep 6, 2016, at 6:43 PM, Maciej Stachowiak  wrote:
> 
> 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

[Maciej Stachowiak]

> On Sep 6, 2016, at 5:27 PM, Darin Adler  wrote:
> 
>> 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

[Darin Adler]

> 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

“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

[Maciej Stachowiak]

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 Garen  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?
> 
> 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

[Michael Catanzaro]

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

[Alex Christensen]

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

[Filip Pizlo]

> On Sep 6, 2016, at 11:07 AM, Geoffrey Garen  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@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

[Geoffrey Garen]

“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

[Alfonso Guerra]

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

[Michael Catanzaro]

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

[Daniel Olegovich Lazarenko]

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