improving the join function

Justin Johansson no at spam.com
Tue Oct 12 08:23:39 PDT 2010


On 13/10/2010 2:02 AM, Andrei Alexandrescu wrote:
> On 10/12/10 9:35 CDT, Justin Johansson wrote:
>> On 13/10/2010 1:28 AM, Justin Johansson wrote:
>>> Yes, "do the darn string version already and cut all that crap".
>>>
>>> This is probably the thing to do to make for familiarity among
>>> library users [of other languages].
>>>
>>> However, if you have an urge to back-end the implementation
>>> of the colloquial "join" by your ideas, do not give up your
>>> dream. So long as it is implemented as your private dream
>>> no one will notice and you will remain internally satisfied. :-)
>>>
>>> - JJ
>>>
>>
>> I think I meant the "ubiquitous join" rather than the "colloquial
>> join".
>
> By both I understand "join as in Python". Right?
>
> Question is, where to stop?
>
> 1. string only (i.e. leave as is)
>
> 2. const(char)[] only (to allow joining char[] values)
>
> 3. various width of char, i.e. why shouldn't you join an array of wstring?
>
>  From 3, the incremental effort to generalize to any type is virtually
> nonexistent, and the effort to generalize to ranges instead of arrays is
> minor. To me these are positives.
>
>
> Andrei

Yes, I agree from a range idiom point of view.

Now, while understanding that D people don't care much for the
XPath 2.0 type system, and not myself caring much for the back-end
implementation, my XPath-ish function signature for this join() function
to preserve the generality that you suggest would be

item() join( things as item()*, separator as item()* );

Of course I'm anticipating an understanding of the above XPath 2.0
function signature syntax, an even then, I suspect my proposed
signature to be too liberal.

Regards, Justin





More information about the Digitalmars-d mailing list