On Fri, 24 Jul 2009 02:21:14 +0200, Jiří Zárevúcky <zarevucky jiri gmail com> wrote:
2009/7/24 Ali Sabil <ali sabil gmail com>:On Thu, Jul 23, 2009 at 10:32 AM, Didier "Ptitjes"<ptitjes free fr>Please comment and argue ;)Could you please explain the rationale behind this change ? What would be the benefit from turning a Map into a collection of Pair ?Efficient iteration over all the Map's elements. Otherwise you'd have to retrieve a collection of keys and lookup corresponding value for every single one of them.
Why not simply make Collections contain objects adhering to a CollectionElement interface which would cover equality testing (about all the collection ever really needs to do), returning of the elements value (which may or may not be the same as the data being equality tested), and generally considered immutable (no standard "set" method). Since the collection only needs to know how to handle CollectionElement's, there's no problem with types. You obtain the element, and invoke it's get_value() method. Set's would hold one piece of data, which they both return through get_value(), and use for equality testing. Map's would be an example where the value data is not the data used for equality testing, and would provide a separate get_key(), and a set_value() to set the non-key data. The equality test would use the key data specified at construction time. For convenience, CollectionElement's could export their data also though a get_as_value() method (or a value property), essentially just wrapping the result from get_value() as a generic GValue (using their inherant type knowledge), which the collection itself could then offer as a get_value() convenience function. (It would probably be better if Vala could construct a property holding compile-time type data... It could then be used as a type at compile time, or a GType at run-time, and would make this whole thing a heck of a lot easier.) For handling of weak keys and the likes, have the collection call a set_owner() method on every element when it's added, with itself as an argument. This allows an element which cares, such as those holding weak data, to register a self-destruct callback. Elements that don't care can then simply do nothing. (Unless there's a better way of achieving this...?) I'm not sure allowing elements to generally remove() themselves is a good idea, because then they all need to retain knowledge of the collection(s) they're stored in. If that IS doable in an efficient manor, then it would be nice if an element could generate an iterator also. -- Fredderic Debian/unstable (LC#384816) on i686 2.6.29-2-686 2009 (up 12 days, 9:04)
Attachment:
signature.asc
Description: PGP signature