Dave Storrs <[EMAIL PROTECTED]> writes:
> In the "Re: Wh<[ie]>ther Infix Superposition ops" thread
>
> On Wed, 30 Oct 2002, Piers Cawley wrote:
>
>> But given a decent Collection hierarchy:
>>
>> my $seen = Set.new($start,$finish);
>>
>> for <> -> $next {
>> print $next unless $next =~ $seen;
>> $seen.insert($next);
>> }
>
> Just a thought...are sets (or other Collection types) something that we
> use often enough that they would deserve to be in the core language? I
> know I've used hashes as no-repeats-allowed sets many times, so clearly
> they are commonly useful. On the other hand, since this can be done,
> maybe there is no need to implement a new core feature for them.
>
> I suspect the answer is "no, we don't need them" but I just thought I'd
> ask; I'm curious about the design reasons either way.
Personally, I'd love to see something like the whole Smalltalk
Collection hierarchy available complete with Bags, Sets, Dictionaries,
OrderedCollections and the whole deal. I note, for instance that
Christian Lemburg has implemented Set::Object, and it's substantially
faster than a hash based implementation for insertion, and marginally
faster for lookup. See
http://search.cpan.org/author/JLLEROY/Set-Object-1.02/Object.pm#PERFORMANCE
for Christian's numbers. I would hope that we could see other
performance gains for other Collection classes.
Taking a quick glance at a handy Smalltalk image, it seems that,
ideally one would want to have Collections in the core so that Hash
could inherit from Collection via Set. But then, anything's possible
at compile time, so one could probably set something appropriate up by
doing 'use Collections'.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
