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

From: FlSt_at_[hidden]
Date: 2005-07-28 16:11:26

Rob Stewart wrote:

>So, I think we're agreed that we're discussing four things that
>can be compared to each other as well as to single values.  The
>supported comparisons are ==, !=, <, >, <=, and >=.  If we're
>agreed, then we can discuss design.
>
I aggree. The other aspects of junctions are kept in mind for later 
discussions.

>For the extraction of elements matching some criteria, you would
>likely use function templates.  For the functionality we've
>whittled down junctions (or whatever name still fits) to include,
>you need types plus namespace scope operators:
>
>[ ... code ...]
>
I modified my implementation so that it implements the most of your 
ideas, like using ranges and call traits. (uploaded to the Boost sandbox 
files vault as flos_junctions_v2.zip). But there are some differences, 
how the operators supported. Please take a look at it. I think there are 
much better ways to do the specialization for the junction types and get 
rid of the XXjunction-classes and provide only XXX_of as template 
classes. But this version has the advantage, that it does all the work 
in one place and the operator implementation is consistent without the 
need of friend relations. Your approach has also it's adavantages, for 
example it's easier to implement optimized versions of the junction 
types. The new implementation is more effecient as before, but i don't 
like the use of boost::dynamic_bitset, because the result can determined 
without storing all results. (Only for one_of a flag or something 
similar is needed). My attempt makes it difficult to make it more 
efficient without ugly hacking.

>A better approach is probably for the operators to be implemented
>in terms of a number of implementation function templates that
>work only on junction<T>'s.  Then, there's no conversion needed;
>the operators just need to call the right implementation
>function.  That leaves the four derived types as just selectors
>for the right operator.
>
>Ideally, junction<T> will hide its range and the implementation
>function templates will be made friends.
>
That is what I did without using a friend relation. 

>What do you think of these ideas for the design?
>
I think there must be a trade-of between your design ideas and my 
implementation proposal. (My implementation should only be a prototype) 
In many points we agreed, but some details are very different. I don't 
like friend relations (I don't see operators as a part of the class, 
they are just syntactic sugar) and I think to let the operators do the 
work for every junction type would produce more duplicated code and more 
operator overloads as neccessary.

>There's still the issue of naming.  Should these be called
>junctions since they don't do all that Perl's junctions do?
>Besides, I think "junction" somehow fits better the notion of
>producing a result container that includes those elements of the
>range that satisfy the criteria.[...]
>
Ok.. I see, that the naming is a problem now. "Junction" and 
"supervalues" are not evident. We have now something like a comparison 
over ranges with a logical linkage between the elements. Would be 
"range_comparison" or "junction_comparison" better?

Sincerly,
 Florian