in reply to Standardized Interface Design for Search tree
The C++ STL then uses these concepts as bases for generic programming using templates. The C++ vector<T> isn't a vector<Object>! It doesn't require that all Ts inherit from a common ancestor (compare the aforementioned Hash::Element). This would not be type-safe (a vector of cars is NOT a vector of vehicles; the former cannot accept a submarine, but the latter can!). Instead, when you sort a vector (you really sort ranges in C++, based on the interval between 2 iterators, but let's keep things simpler than they really are...), the compiler generates code that assumes it can meaningfully compare T t1, t2; by checking whether t1 <= t2.
Perl is not C++. It isn't type-safe: variables don't really have types (you can say my Foo $foo, but the compiler cannot enforce this type safety). And it doesn't have templates; you can see these as only necessary for a type-safe language (so Perl doesn't need them), or as allowing for much better compilation, paying the price of type safety for vastly faster execution. But this should not prevent us from stealing!
So here's what I'd propose:
Given these rules, you can define your data structures.
- A search tree organises things of one or more types.
- For any $a,$b in the search tree, $a->le($b) must be defined (i.e. "$a->can('le')").
- This relation must be a pre-order: if $a->le($b) and $b->le($c) then $a->le($c), and always $a->le($a).
- No inheritance of any kind is required to be defined.
- (Optionally:) you may provide a coderef for comparisons; if you do not, the following will be used:
sub { $_[0]->le($_[1]) }
But how can we implement them cleanly? Well, some things (e.g. Math::BigInts) are compared using <=. For such MyObjs, we wrap as follows:
(This pattern is usually called a "mixin": Numeric is a base class which only makes sense as part of multiple inheritance; you mix it in to some other class). Now MyInts are Math::BigInts which can be put into a Demerphq::SearchTree! If you have plain numbers, you can just bless them into Numeric, and they're ready for use in your search tree.package Numeric; sub le { $_[0] <= $_[1] } package MyInt; our @ISA = qw(Math::BigInt Numeric);
Of course, a similar strategy would give you Lexical, if needed. And a Hash::Element can be similarly wrapped by translating the method cmp into le.
Since a common base class for contained things buys us nothing in Perl (and almost nothing in other languages), we don't bother to make us of it.
If you really wanted to be creative, you could use TheDamian's multimethods to give a more symmetric definition. I wouldn't bother, though.
The most important differences in what I propose from C++ are that only objects can go into a search tree (C++ can put anything in any container, as long as it matches the concepts -- and these never require any methods of the "thing"), that there is no type safety, and that you lose out on C++'s optimization opportunities.
But then, if you want C++, you know where to get it...
Footnotes:
- "Way To Do It" is (I hope!) an unregistered trademark of Larry Wall.
Update:
I forgot. We have no SPL.
|
---|
Replies are listed 'Best First'. | |
---|---|
•Type Safety, was Re: Re: Standardized Interface Design for Search tree
by merlyn (Sage) on Jun 25, 2002 at 15:18 UTC |