improving the join function

[Daniel Gibson]

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