On Mon, 3 Aug 2009 19:21:18 +0000 (UTC), Jan Hudec <[email protected]> wrote:
> Fredderic <magen...@...> 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 clear
>> list1.remove_by_list(list2)
> list1.remove_first_of(list2); // only removes one; hopefuly clear
>> list1.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)
signature.asc
Description: PGP signature
_______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
