xxxInPlace or xxxCopy?
Jonathan M Davis
jmdavisProg at gmx.com
Fri Jan 21 12:21:55 PST 2011
On Friday, January 21, 2011 10:47:01 so wrote:
> > replace is clearer in the first case, because you're getting the return
> > value.
> > ...
>
> I am really trying hard to understand this, but your reasons for first is
> clearer then the second makes no sense to me i am sorry.
> I still think second is clearer, but whatever, as long as i can see the
> interface or the doc, i am fine.
>
> string replace(string, ...);
> void replace(ref string, ...);
The issue is when you don't look at the documentation or trying to avoid having
to look at the documentation. If you see
auto result = replace(str, "hello", "goodbye");
it's quite clear that a copy is taking place. And if a copy/slice is taking
place, then that is what you would normally see when replace is used. However,
if replace alters the array in place, then
replace(str, "hello", "goodbye");
would be what you would normally see. And without looking at the documentation,
it's not clear whether that is doing it in-place or if you're throwing away the
return value. However, in the case where replace does a copy/slice, it _is_
clear, because the return value is saved.
So, if copying/slicing is the default, then you won't _need_ to read the
documentation to know whether a copy/slice is happening or whether it's
happening in-place, because the code itself will make it obvious (unless you
screwed up and forgot to assign the return value to a variable or pass it to a
function). But in the case where in-place is the default, it is _not_ obvious by
reading the code. Sure, once you read the documentation, you'll know. But you
have to read the documentation. So, copying/slicing by default is immediately
obvious whereas in-place is not.
> > Regardless, I don't see anything wrong with naming functions in a manner
> > that
> > implies that a functional style is the default
>
> I am not against enforcing such a rule, i am against doing it implicitly
> and work with assumptions.
> Just check boost/string/replace, they have in place replaces default too.
> You might not like boost (some don't) but it is the closest example to D.
If you want consistency among your function, then you have to pick either
copying or in place as the default. That doesn't necessarily mean that _all_
functions must _always_ be named that way (e.g. the current behavior of sort is
an interesting example since it does _both_). However, if you're going for
consistency, then you have to pick one or the other. Unless you want to
explicitly put Copy and InPlace in all of the array functions and not have any
without it, you're going to _have_ to deal with the fact that a function without
Copy or InPlace in its name is still going to have to do one or the other
(unless you're talking about a function which is just querying something about
an array rather than manipulating it - like cmp).
So, when you have a function like replace, you have to choose whether it's going
to do it in place or copy/slice the array. A different version of the function
with a different name (such as replaceCopy or replaceInPlace) then deals with the
other case. Phobos has already been going for the default of copying/slicing
rather than doing it in-place. Given that strings _have_ to be copied or sliced
and that strings are the most common type of array, making copying/slicing the
default makes good sense.
It's fine if Boost wants to pick in-place as the default. That's their choice.
They're also dealing with a different programming language with different pros and
cons. Personally, I prefer that copying/slicing be the default if it's efficient
enough to do so, since that promotes a functional style of programming, which is
going to tend to be more straightforward and less error-prone, but if in-place
mutation was going to be the normal use case (like is probably the case with
Boost), then it's probably better to make in-place the norm, because that's the
way that's going to be used most. However, since that's _not_ the way that's
likely to be used most in D (due to strings having immutable elements), I really
don't think that in-place as the default makes the most sense for D.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list