[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: modules for generic unordered sets and mappings
From: |
Jose E . Marchesi |
Subject: |
Re: RFC: modules for generic unordered sets and mappings |
Date: |
Sun, 04 Jul 2010 13:40:07 +0200 (CEST) |
> An unordered set is effectively a mapping between a key and a boolean
> (membership) so I am not sure what would be the benefit of returning
> something like 'gl_set_node_t' instead of the boolean directly. In
> case we want to change the membership status for some key then we
> simply check and remove/insert.
Think of set of composite values (a struct), of which one serves
as a key. You may want to query whether a dummy { key, x, y, z }
is in the set, solely to find some real element with a matching
key. But then, is the set merely a special case of a map? Do you
want to enforce that the key be stored separately from the "value"
by forcing the above to be implemented as a map rather than as a
set?
Hm, good point. I think that I may be mixing two different things:
set membership and searching in the contents of the set. I will try
to clarify myself:
- A membership function would get an element and would return a
boolean indicating whether the element is contained in the set. A
set cannot contain duplicates.
Having two explicit types of elements (pointers and blobs), the set
abstraction can provide super-fast equality functions by using a
hash table, or whatever. But that implicit function would not be
very useful for pointers, so we could let the user to specify an
'equal_fn' callback at set creation time.
- A 'search' function would use some search criteria to select a
subset of the elements in the set.
The 'gl_set_search' function could then return the first element
matching that criteria.
More than one element could be matched by a single search criteria,
and we could define many different searching criteria on the same
set. For example, given a set of streams we may want to search for
EOFs.
The 'equals_fn' function described above and used for membership
testing would not fit for searching purposes, since it would
evaluate to 'true' only for one element contained in the set.
I would use a simple function ELEM->bool for membership testing (no
duplicates) and then rely on the usage of iterators to implement
searches.
Maybe I am making a mess out of a simple concept, though. I just got
back from my holidays and I got a lot of sun on my head lately :D