>> "Pure OOP style is always the right way" Sorry, that's a typo, I meant "not always" of course. The examples clarify that.
My point was that "release", "take" and "move" have well-established and different meanings (with connotations that may or may not be logical without the same background): * release will free the memory if ref_count = 0 (Obj-C/CF on Mac/iOS) * move just moves the ownership without freeing (C++) * take removes and item from the collection and returns it (the ownership is implicitly passed as well) (Java, C#, but not only). So map.take() means that I still need that object most likely, and map.remove() means that : feel free to throw the object to trash. That are connotations I've seen in my practice. On Tue, Sep 6, 2016 at 6:14 PM, Alfonso Guerra <hupernike...@gmail.com> wrote: > > > 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
