[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

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
  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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]