<div dir="ltr">>> "Pure OOP style is always the right way"<br><div>Sorry, that's a typo, I meant "not always" of course. The examples clarify that.</div><div><br></div><div>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):</div><div>* release will free the memory if ref_count = 0 (Obj-C/CF on Mac/iOS)</div><div>* move just moves the ownership without freeing (C++)</div><div>* 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.</div><div>That are connotations I've seen in my practice.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 6, 2016 at 6:14 PM, Alfonso Guerra <span dir="ltr"><<a href="mailto:huperniketes@gmail.com" target="_blank">huperniketes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 6, 2016 at 4:29 AM, Daniel Olegovich Lazarenko <span dir="ltr"><<a href="mailto:danielo@opera.com" target="_blank">danielo@opera.com</a>></span> wrote:<br><div><br></div><div>..</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>* "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.</div></div></blockquote><div><br></div></span><div>That doesn't make sense to me. Why would the object "bowl" be passive, but not "fred"?</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>We treat bowl as a passive bag of data, and expect others to take from it.</div></div></blockquote><div><br></div></span><div>I see. Like an actual bowl in the real world?</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>It's pretty easy to understand and remember, it makes intention more clear than say "bowl.removeCandy()".</div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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().</div></div></blockquote><div><br></div></span><div>Do you have a link for that? The closest thing I see to that example (<a href="https://isocpp.org/blog/2014/12/myths-2" target="_blank">https://isocpp.org/blog/2014/<wbr>12/myths-2</a>) is demonstrating the exact opposite, that a non-OOP solution provides better performance by eliminating the dereferencing of a pointer.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Naming is fun.</div></div></blockquote><div> </div><div>Learning how to communicate across cultures of all types is fun. ;-)</div><div><br></div><div><br></div><div>--</div></div><div><div dir="ltr">Alfonso Guerra<div>Founder/CEO</div><div>Apokalypse Software Corp.</div><div><a href="tel:%28626%29%20667-4285" value="+16266674285" target="_blank">(626) 667-4285</a></div></div></div>
</div></div>
</blockquote></div><br></div></div>