Re: [boost] Interest for a perl6-like-junctions-class?

From: FlSt_at_[hidden]
Date: 2005-07-25 11:15:48

Hello Rob.

>>[...]
>>
>I have a few questions about your design:
>
>   Why "super position" versus Perl's "junction?"  When
>   describing the enumerators, you use the Perl terminology,
>   apparently because it makes sense.  Frankly, I don't "get"
>   "super position."
>
Before it was a built-in feature of Perl, something similar was 
available as a CPAN module called Quantum::SuperPosition. This naming 
comes from the quantum physics where elementary particles can have more 
than one state, called super position. But i think its more evident to 
call it "junction". (Furthermore "super position" sounds overblown ;-)

>   Why is the junction type a template parameter?  Did you
>   consider making four separate types?  Does using one make it
>   easier to compare instances of the four types?  Should the
>   client have to care about that?  IOW, I think writing
>   disjunction<T> is simpler and clearer than
>   super_position<ANY, T>.  Other name possibilities like
>   "any_of" are possible, too.
>
I must admit that i don't spend time in tinking about this until now. 
The idea behind the diffrent types was, that i don't know how to handle 
assignments between diffrent junction types. I wrote an explicit 
constructor for assigning the eigenvalues. But what should the 
assignment operator copy? Only the values or also the junction type? 
Would it be better to store the type as an attribute? An another idea i 
had while writing this template class was, that i write a junction base 
class and make the is_result_true(...) function virtual and inherit for 
every junction type. That would fit with your second naming suggestion, 
which i like, because its more conform to the Perl-implementation. I 
aggree that writing super_position<ALL,T> is ugly, not only for the 
clients ;-). The comparisons between diffrent types is no problem, 
because the only diffrence between the junction types is the 
is_result_true() function. Has anyone an idea?

>   Why would one change the Container parameter?  Why would the
>   client of this class care about the associative container
>   being used to implement it?
>
I'm using boost::hash_set<T> in my own applications. And i think there 
are cases where std::multiset<T> also can make sense. That was the 
reason for this optional template parameter.
For example this is not possible with std::set<T>: 
http://www.metaperl.com/talks/p6-junctions/slide5.html

>I noted that you wrote your loops to repeatedly evaluate x.end().
>Algorithms avoid that problem; if you need your own loops, you
>should hoist calls to end() out of the loop.
>
That was my laziness, but you are right. :-)

Thanks for your fair comments.

Sincerly,
Florian