Andrei Alexandrescu schrieb:
On 10/11/2010 10:34 PM, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union() - a real join isn't needed in std.string anyway, but when
join()
is deprecated in std.string you can implement a real join in
std.algorithm without causing too much confusion).
I think union() is a worse name than join(). The discussion was to
generalize within reason std.string.join, which is present under that
name and with that functionality in many other languages and libraries.
Andrei
Okay, union does kind of suck, because it implies set semantics (and
thus no ordering).
What about concat()?
It seems like join() is expected to work this way for strings.. but as a
generic algorithm working on kind-of-cursors?
I for one would expect join() in its relational sense to work on things
quite a bit more structured than just ranges (there's need for indexes
etc). Therefore, if relational join() will be introduced later,
overloading will disambiguate it. There's no reason to worry.
Andrei
Of course indexes would speed things up, but as mentioned before join() would work ok on almost(*)
all ranges (with O(n^2) complexity) and a lot better on std.range.SortedRange.
Because the user would provide a predicate (that should use the same comparator that was used to
sort the range) no additional structure (metadata like needed for natural join) would be needed.
(*) the inner range needs to be a FordwardRange so it can be traversed multiple
times
