From: "Jeff Flinn" <TriumphSprint2000@hotmail.com>
<FlSt@gmx.de> wrote in message news:42E51034.7040508@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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;