what should the default value for $sep be for @array->join

[notbenh]

This is an extension of #241

Currently join defaults to undef, causing warnings. Is it really what most users would expect. I can think of more cases where I've joined on a space then I joined on nothing, thus I think that to be a tad more useful in the future [read v3] that we could default to something like q{ }, though this will alter the current behavior. Thus the open ended question of what does the group think.

[exodist]

Personally I would lean to making join() with no separator fatal. Really if someone does not fill it in they are either making an assumption about a default (Which as you have all said, what would someone expect?) or they forgot it. If we add a default and they just forgot it then it can be a subtle hard to track bug. If it is fatal, specially with croak or even confess it removes the chance for a bug, and points to where you made your mistake.

[exodist]

We could also add a second function. @Array->join(default to ', '), @Array->concat(default to ' '). or if concat already exists and has '' (what I would expect) then @Array->sentance( default to ' ' ) and when given a seperator they all act identically

Note, I can't think of good method names for this, and think it is probably over-kill I still think fatal on no seperator is best.

[schwern]

We're straining REALLY HARD to make join have a default. Keep in mind things don't have to have defaults.

• Are we saving anyone real effort?
• Will the writer predict the right behavior?
• Will the reader predict the right behavior?
• Will they remember the right behavior?
• Will we save the writer more time by giving them an error early rather than getting the default wrong?
• Will we save the reader more time by making the separator explicit?

I think the most damning part is that there's no sensible rule which predicts what the default will be. Its essentially the result of whatever conversation we have right now. If we pick , (or is it ,) and you read the docs and see its , how will you remember that in three weeks time? To contrast again with rounding, rounding in the real world has agreed default behaviors. You round to the nearest integer and .5 gets rounded up. You can remember that behavior as "round defaults to what people normally do". People don't normally join strings. When they do, they can use all sorts of different separators for different purposes.

In sum, defaults should either be A) immediately obvious or B) easy to remember once you've looked them up or C) throw an error to let you know you have to supply a value. This is neither A nor B, so it must be C.

In the best case, we're saving the user from writing ', '. Not everything has to have a default behavior. That we're having this much discussion over such a trivial amount of typing is another good indication that its not worth it. Its a required argument, throw an exception.

[myfwhite]

I think the obvious default for join is $" ( or $LIST_SEPARATOR ), which defaults to space. But having it be that is kind of redundant, because then @a->join is just the same as "@a". I guess it's less redundant when you have a list instead of array or when you have a function call returning an array. I personally use join a lot with all different separators, but rarely with a space, so what is (to me) the obvious default is actually not useful. Having no default is perfectly fine for join. Changing it to throw an exception is not a problem.

[notbenh]

+1 for using $" that makes much more sense as it already is the expected value and will continue to remain the expected value when overridden.

[schwern]

My thoughts on $" are as follows...

Pro: It's the default behavior of "@foo".
Rebutal 1: Does this buy the writer much over "@foo"? (@myfwhite points out some cases when yes it does)
Rebutal 1.5: Does this buy the writer much over @foo->join(" ");
Rebutal 1.75: Is that benefit to the writer worth the reader having to remember what @foo->join does?
Rebutal 2: Of the different sensible default behaviors so far, is the user going to guess $" over ',', ', ' or ""?
Rebutal 2.5: How many Perl programmers even know about $" and "@foo"?
Rebutal 3: As @myfwhite points out, it's not a terribly useful default.

Con: It ties the local behavior of a method to a global variable.

That con is a major interface no-no. If somebody somewhere in the code changes $" then suddenly the behavior of completely unrelated code silently changes.

And, back to the root, do we need a default here?

[exodist]

My 2 cents: if we must have a default use $", I hate $", but it makes the
most sense. I much prefer throwing an exception without an arg: I think
most cases of no args will be a mistake, and an exception helps the
programmer. A default prevents the catching of errors, and anyone using the
default will have to look it up frequently when writing code just to be
sure it does what they think. I suspect even people who know the default
will put it in just to save time looking it up.
On Mar 27, 2013 2:19 PM, "Michael G. Schwern" notifications@github.com
wrote:

My thoughts on $" are as follows...

Pro: It's the default behavior of "@foo https://github.com/foo".
Rebutal 1: Does this buy the writer much over "@foohttps://github.com/foo"?
(@myfwhite https://github.com/myfwhite points out some cases when yes
it does)
Rebutal 1.5: Does this buy the writer much over @foo->join(" ");
Rebutal 1.75: Is that benefit to the writer worth the reader having to
remember what @foo->join does?
Rebutal 2: Of the different sensible default behaviors so far, is the user
going to guess $" over ',', ', ' or ""?
Rebutal 2.5: How many Perl programmers even know about $" and "@foo"?
Rebutal 3: As @myfwhite https://github.com/myfwhite points out, it's
not a terribly useful default.

Con: It ties the local behavior of a method to a global variable.

That con is a major interface no-no. If somebody somewhere in the code
changes $" then suddenly the behavior of completely unrelated code
silently changes.

And, back to the root, do we need a default here?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/244#issuecomment-15553740
.