> First is the choice of arrays verses hashes as the choice for set storage.
> Arrays are obviously easier to construct, but hashes are both faster
> implementations, and easier to determine membership.
Well in fact I'm interested by such functions in order to manipulate
lists
of scalars (1, 'toto') and to manipulate lists of hash table references
( { name => 'joe', age => 21 }, { name => 'sam', age => 27 } )
and I'd like to use these functions independantly of the array content
type.
> Next, what subset of the set-theory should be implemented. Obviously you
> refer to the basic and / or / xor, but in real practice, the other operators
> can be very useful. Chaining operators (especially with array-based-sets)
> can be a performance nightmare.
Well, the more functions will be implemented, the happiest I will be.
But in pratice I really often need Union, Intersection, Difference, In,
Not In.
This is the minimum for me.
> Next, these operations can easily be implemented as a module (written out to
> C if you like), and simply distributed with the core library.. Since some of
> us are working to tighten down on the core of perl and break things out into
> modules, this obviously runs counter to our goal.
Maybe this could be in a module.
But for me, these functions are so natural when manipulating arrays,
that it
seems normal they will be part of the language.
> Even the odd form of passing two arrays to the function could still work
> with a module through the use of prototypes ( sub union(\@\@) { ... } ).
> Unfortunately, because of this, you would require that only true arrays can
> be passed. I would much rather be able to instantiate a new set on the fly
> as in:
> @u_set = union( \@set_a, [ 1 ] );
Ok, for the call using references.
