Straw Poll: Return True or False?
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
I see three different outcomes here. 1. The item is found and deleted. Final result: the item is not in the collection. 2. The item is not found in the collection. Final result: the item is not in the collection. 3. There is an error while either looking for the item or trying to delete it. Final result: unknown (unpredictable) Since when the function works fine, the item is finally not in the collection (therefore that's something you already know), it would be useful to use the return value to know something you wouldn't know otherwise, like if the item was there in the first place or not (TRUE if the item was deleted, FALSE if it wasn't there). In case 3, where something went wrong, I think the best choice is to throw an exception, since it's an abnormal case. Besides, it can go wrong in many different ways, and a TRUE/FALSE result wouldn't help much in finding the cause.
-
Number 1 is the way I would go with it. Actually I can't see how anyone would ever pick 5 unless they are some sort of control freak. 1 accomplishes the job painlessly.
"110%" - it's the new 70%
You're right. I am a freak. Just how much of a freak, you'd never believe. But apart from that, I am not convinced by your argument: 1. There is nothing in the question that says you *have* to define TRUE as success. In some languages, 0 is the code for success, and this casts to FALSE. 2. The purpose of the call *could* be to free up the disk space occupied by the item, in which case, the function has *failed*. So I would return FALSE. Alternatively, both (1) and (2) could be the case. Which would make your answer correct, but in a rather freaky sort of way, no? My blog:http://allwrong.wordpress.com[^]
-
How so? Psuedo Code if (list.contains(item)) { bool bOK = list.delete(item); //Do something here we bOK if you want } This would skip delete calls to items that no longer exist. The delete just deletes, it doesn't do a check on existance.
Jon Raynor wrote:
This would skip delete calls to items that no longer exist. The delete just deletes, it doesn't do a check on existance.
Not necessarily, unless item.contains() returns a reference (or the collection holds a reference to the last looked up element internally in some way or another) to the item it would not skip the second lookup for items that exist and will be deleted. To avoid the second lookup you would have to do something like this: ITEMREF ref = NULL; ref = list.contains(item); // NULL = no item found, non-NULL is ref to item if(ref != NULL) { BOOL bOK = list.delete(ref); if(!bOK) shoutOutErrorMessageToTheWorld(); } Maybe this is what you meant, but your pseudo code does not indicate that.
-
Jon Raynor wrote:
This would skip delete calls to items that no longer exist. The delete just deletes, it doesn't do a check on existance.
Not necessarily, unless item.contains() returns a reference (or the collection holds a reference to the last looked up element internally in some way or another) to the item it would not skip the second lookup for items that exist and will be deleted. To avoid the second lookup you would have to do something like this: ITEMREF ref = NULL; ref = list.contains(item); // NULL = no item found, non-NULL is ref to item if(ref != NULL) { BOOL bOK = list.delete(ref); if(!bOK) shoutOutErrorMessageToTheWorld(); } Maybe this is what you meant, but your pseudo code does not indicate that.
list.contains(item)) would return true or false much like does when using lists. Your code is essentially the same because your looking for an object reference. The psuedo codee that I wrote assumes that list.contains(item) would return true or false. It doesn't return a reference to the item. Sorry if that was unclear.
-
You're right. I am a freak. Just how much of a freak, you'd never believe. But apart from that, I am not convinced by your argument: 1. There is nothing in the question that says you *have* to define TRUE as success. In some languages, 0 is the code for success, and this casts to FALSE. 2. The purpose of the call *could* be to free up the disk space occupied by the item, in which case, the function has *failed*. So I would return FALSE. Alternatively, both (1) and (2) could be the case. Which would make your answer correct, but in a rather freaky sort of way, no? My blog:http://allwrong.wordpress.com[^]
I guess I just like to stick to the realistic and practical side of things, maybe if I had taken a CS course in university these ivory tower discussions would be of interest to me. In the real world 99 times out of 100 my answer would be the correct one.
"110%" - it's the new 70%
-
I guess I just like to stick to the realistic and practical side of things, maybe if I had taken a CS course in university these ivory tower discussions would be of interest to me. In the real world 99 times out of 100 my answer would be the correct one.
"110%" - it's the new 70%
-
I always envisioned the universe as a terinary computer.
This statement was never false.
-
Chris Maunder wrote:
What if an incorrect parameter was passed (eg item # -1), or the collection was actually a database table and you coldn't open the table? False could mean "Something bad happened and there's no way the item could be removed", and true "The item is no longer there".
Correct me if I'm wrong, but isn't your exception handling supposed to deal with the "Something bad happened"?
"We are all repositories for genetically-encoded information that we're all spreading back and forth amongst each other, all the time. We're just lousy with information." - Neal Stephenson
An exception doesn't have to be "Something bad happened" but rather "Something exceptional happened".
This statement was never false.
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
If the return must be boolean, than false: this takes into account the possibility of an error in the specification of the deleation-item request. Since no further restrictions were given, the item could have come from user input (and thus guaranteed to be in error). Allowing for this possibility, failure to delete a non-existant item is not a proper indication of success. Other respondants have indicated a variety of options. One which I find most satisfying would be returning the count of items deleted, or negative upon some sort of failure (to be defined). PHilosophically, true is not correct. Think about when you type in a delete command from the command prompt! Balboos HaGadol
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
Why are you returning anything? How about an item not found exception? If you expect the item to be there and it isn't then you have yourself an exception. If you don't care that it's not in there ignore the exception. Either way, the user of this code doesn't have to decide what you meant by returning true or false.
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
That's only because you allowed either TRUE, or FALSE, but no alternatives. All the programming language I used does not deal with direct memory management. Therefore in reality, most of my collection removal functions return an Object, therefore if the Object is found and to be removed from the collection, this object will be returned, if nothing is found, null will returned. LOL
-
list.contains(item)) would return true or false much like does when using lists. Your code is essentially the same because your looking for an object reference. The psuedo codee that I wrote assumes that list.contains(item) would return true or false. It doesn't return a reference to the item. Sorry if that was unclear.
I found that Crystal Reports' Parameter collection has a Find() that returns a reference (or null). Unfortunately its Contains() requires a reference, as in "is this item in the list?" But there is no ContainsKey() that returns true/false!!
-
I see three different outcomes here. 1. The item is found and deleted. Final result: the item is not in the collection. 2. The item is not found in the collection. Final result: the item is not in the collection. 3. There is an error while either looking for the item or trying to delete it. Final result: unknown (unpredictable) Since when the function works fine, the item is finally not in the collection (therefore that's something you already know), it would be useful to use the return value to know something you wouldn't know otherwise, like if the item was there in the first place or not (TRUE if the item was deleted, FALSE if it wasn't there). In case 3, where something went wrong, I think the best choice is to throw an exception, since it's an abnormal case. Besides, it can go wrong in many different ways, and a TRUE/FALSE result wouldn't help much in finding the cause.
0. Unable to determine existence/nonexistence (very rare)
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
In this case, write a unit test first, and see how it works out.
-
Isn't "butt" used too many times in that article!? :) "Rebutt" sounds funny.:) As for the rest of the content (not that I read anything, just to sound smart;)), I don't see whether and when programming will ever require 4 logical values for anything. The same effect can be achieved by using two normal logical values twice. Three logical values sounded a bit more logical to me:), but in some weird way I'm happy we only have two. Don't know why...