Fredderic <magen...@...> writes:
> remove_all() is just a bad name to begin with. There are two separate
> ideas here:
I concur. It is not clear to which side the 'all' qualification applies.
> 1) removing all items in list1 that have a matching item in list2
>
> 1,1,1 from 1,1,1,1,1 gives an empty list
>
> eg. impl.: iterate over items in list1, checking list2 for a matching
> item, and remove it if found. ("greedy" matching?)
I would suggest calling this 'remove_all_of'.
(The name exists in STL's basic_string)
> 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.
> ...
> 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.
> 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.
> 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.
Not like this, but in the form of 'update_from' operations (on maps),
where given two maps, one needs a list of keys that are only in
the first one (deleted), list of keys that are only in the second
(added) and list of keys that are in both with different values
(changed).
However, I think something with callbacks might do better service
here -- often the lists don't need to be generated, only processed.
> 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
> list2.remove_from(list1)
Wouldn't this be equivalent of
list1.remove_by_list(list2); (or list1.remove_first_of)
?
In any case, please don't create constant methods that modify
parameters. List2 is constant in all the above.
> list2.remove_all_from(list2)
Again, this would be equivalent of
list1.remove_all_by_list(list2); (or list1.remove_all_of(list2))
, right? Again, please no constant methods that modify parameters.
> and lastly for completion...
>
> list1.split3way(list2, only1?, only2?, both?) - where the three target
> list arguments may be undefined to ignore that case, and should be
> existing lists into which the relevant items will be added (allowing
> the result of several such splits to be combined).
Hm, I would be rather thinking about:
list1.diff(list2, void delegate(item, side));
where side would be an enum { LEFT, BOTH, RIGHT }.
I would say, that this algorithm should do:
- for sets the split above, so:
- items in list1 - list2 would be called with LEFT
- items in list2 - list1 would be called with RIGHT
- items in list1 & list2 would be called with BOTH
- for maps, it could additionally pass in the values
- for bags, it could pass in the counts
- for lists (order-preserving collections) it could calculate
the difference, though that's a bit complex.
Regards,
Jan
--
- Jan Hudec <[email protected]>
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
