On Mon, 3 Aug 2009 19:21:18 +0000 (UTC), Jan Hudec <bulb ucw cz> wrote:
Fredderic <magentus > writes:This is more like what I thought of when I heard the name remove_all()... Except that my immediate thought was "take this single item, and remove any identical items from the list".I agree. remove_all() sounds more like operation that takes a single item and removes all matches. That's why I suggest adding the _of suffix.
I do like the *_of theme in reference to lists...!
2) removing all items in list1 that have a corresponding item in list2 1,1,1 from 1,1,1,1,1 gives 1,1 eg. impl.: iterate over items in list2, checking list1 for a matching item, and remove it if found. I'd personally call this subtract() or remove_from() or something.I like the subtract() name. It is that set operation. Alternatively along the theme above it would be remove_each_of(), because it removes (one instance) of /each/ /of/ the items specified.
There was another thread about set operations on collections... I think this has just become a vote for doing that, too...
I've personally used this type of operation more often than the operation in #1 above. (If practical, making remove_from() a method of list2 would seem the most logical.)Please, no. Methods should preferably modify their invocant rather than arguments. It makes the code easier to read if methods only modify their invocants and not other parameter, since it's fewer side-effects to look for.
Yeah, in hindsight, I think I agree, actually...
Although the one operation I use more than either of these, is a three-way-split. Given two lists, produce the three lists containing those items only in list1, those items only in list2, and those items in both lists. Of course even there, there's a question of whether to use a greedy or non-greedy matching of items.I first thought that I never saw a use of this, but I actually did.
It's often a messy thing to do efficiently when it's needed. Perfect to have supported in a collections toolkit. What usually what ends up being done from what I've seen, is that you process one list for unique and shared items, and then run the second list looking only for the unique items, but you end up doing two complete passes. It's a lot easier when both lists are sorted, because you effectively merge-sort the lists, without actually doing the merge-sort. But most other cases are messy to do efficiently, so it ends up being done the easy way instead.
list1.remove(item)list1.remove_first(item); // if we wanted to be clearlist1.remove_by_list(list2)list1.remove_first_of(list2); // only removes one; hopefuly clearlist1.remove_all(item)Yes, I agree.list1.remove_all_by_list(list2)list1.remove_all_of(list2); // just a tiny bit shorter
+1
and lastly for completion... list1.split3way(list2, only1?, only2?, both?)However, I think something with callbacks might do better service here -- often the lists don't need to be generated, only processed. list1.diff(list2, void delegate(item, side)); where side would be an enum { LEFT, BOTH, RIGHT }.
True enough... Now if only Vala anonymous functions could be passed extra variables, other than member variables of the object from which it was defined (ie. the old create a struct, fill it with what you're going to need, and pass it as the data with a self-destruct clause). Though I suppose that also depends on closures, rather than just a callback and maybe a user_data pointer. -- Fredderic Debian/unstable (LC#384816) on i686 2.6.29-2-686 2009 (up 8 days, 15:00)
Attachment:
signature.asc
Description: PGP signature