Jonathan M Davis schrieb:
On Monday 11 October 2010 20:34:41 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?
std.algorithm already has some operations that are also in the relational
algebra (setDifference, setIntersection, setUnion, Filter, even Group
(like in group by) etc), adding a join (as in relational algebra join)
implementation would only make sense - but how are you gonna name that
thing if join() is already taken for some kind of "concatenation with
additional seperator"? Sure, "setJoin" would be available, but having both
join and setJoin doing completely different things would be confusing.
What about something like
char[] concat(char[][] words, char[] sep="") // or sep=null
in the string case and something equivalent in the ranges case?
Cheers,
- Daniel
Really. It's not that hard to have a function with a name that means different
stuff in different contexts. join is an excellent name for what join() does. Yes,
there are joins in database which are different, but so what? Nothing in
std.algorithm has anything to do with databases. We may end up with a module
that does, and maybe it'll have a join() function too, but that doesn't mean
that std.algorithm can't have one. As others have pointed out, there are other
languages which have a join() function which does essentially the same thing as
the one in std.string. I say leave it as join(). It's a fine name, doesn't
conflict with anything, and doesn't preclude the name being used in database code
later.
- Jonathan M Davis
It's not about database code (and not primarily about strings or std.string), it's about
std.algorithm code.
It makes perfect sense to use database-like operations on arrays/containers/iterators (and thus
ranges), see LINQ[1].
[1] http://en.wikipedia.org/wiki/LINQ
