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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-25 14:59:07

From: "Jeff Flinn" <TriumphSprint2000_at_[hidden]>
> <FlSt_at_[hidden]> wrote in message news:42E51034.7040508_at_gmx.de...
> >>
> >>   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 ;-)
> 
> Perhaps part of the confusion is that "superposition" is a single word and 
> not two. Merriam Webster defines superposition:
> 
> 1 : to place or lay over or above whether in or not in contact : SUPERIMPOSE
> 2 : to lay (as a geometric figure) upon another so as to make all like parts 
> coincide

It's still not very good at communicating the potential in this
context.

> That said, the functionality(in the 1st example) appears to me as a 
> compile-time-set of values. Perhaps mpl already has much of the needed 
> facilities to say(for the scalar case):
> 
>     if( compile_time_set<1,4,9>().count( dave ) ) ...
> 
> Reading the link describing junction even further, it appears that std::set 
> provides some of the desired functionality. There have been at least a few 
> posting here and on comp.lang.c++* discussing making set operations more 
> complete. I've been finding myself addressing these issue often enough these 
> days to look at implementing a more general solution.
> 
> So rather than creating new(as far as C++ is concerned) terminology, I'd 
> find general expansion of set manipulating functionality more useful.

There are many things that one can do with more fundamental
components.  The question is whether those things can be
expressed better using a new component (where better can be
interpreted variously).

For example, using std::set where std::vector (or similar) works
better is premature pessimism.  My last post on this subject
suggested that the "all," "any," and "none" cases could be
implemented using std::vector.  Putting such functionality on
std::set means you pay with higher per-element overhead and
slower iteration.

In that case, rather than coercing std::set (or std::vector) to
meet a new requirement, which enlarges its interface, you use it
to provide the new behavior via composition.

A junctions component also seems worthwhile because it raises
one's awareness of the functionality and its possible
application.  By contrast, one isn't likely to think of
"junction" when looking for a solution to a problem.  Thus,
adding the functionality to std::set, for example, is likely to
put the functionality in a known component, increasing the
chances one will see the functionality as a solution.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;