Bill Baxter:
> It has been pointed out though, that dup is a "shallow copy" in D's built-in usage.  If you want a deep copy operation, there is no precedent in the base language, I believe.  Clone is a good one to standardize on for deep copies, I think.

I see.
Probably the more readable & intuitive names are "copy" and "deepcopy". But "dup" is already present, so it has to be accepted, I presume.
What about "deepdup" for the deep version instead? :-) It's more easy to remember its meaning (and I presume it's not that commonly used to deserve a very short name).

Bye,
bearophile

On Wed, Oct 1, 2008 at 5:55 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> Bill Baxter:
>> It has been pointed out though, that dup is a "shallow copy" in D's built-in usage.  If you want a deep copy operation, there is no precedent in the base language, I believe.  Clone is a good one to standardize on for deep copies, I think.
>
> I see.
> Probably the more readable & intuitive names are "copy" and "deepcopy". But "dup" is already present, so it has to be accepted, I presume.
> What about "deepdup" for the deep version instead? :-)

Heh,  made me think .deeppoop when I first saw that.

> It's more easy to remember its meaning (and I presume it's not that commonly used to deserve a very short name).

I like clone.  It's used pretty commonly in other languages.  I'd rather not follow up one slightly odd-ball name with an even more bizarre one.  But it's not gonna be anything more than a convention anyway, so you're free to name it .deepdup if you like in your libraries.

--bb

Bill Baxter:
> I like clone.  It's used pretty commonly in other languages.

Java?


> I'd rather not follow up one slightly odd-ball name with an even more bizarre one.  But it's not gonna be anything more than a convention anyway, so you're free to name it .deepdup if you like in your libraries.

If the D convention is clone I'll use clone! :-) Using different conventions is generally bad.

Bye,
bearophile

On Wed, Oct 1, 2008 at 6:53 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> Bill Baxter:
>> I like clone.  It's used pretty commonly in other languages.
>
> Java?
>

I've seen it used in C++ libs too.

>> I'd rather not follow up one slightly odd-ball name with an even more bizarre one.  But it's not gonna be anything more than a convention anyway, so you're free to name it .deepdup if you like in your libraries.
>
> If the D convention is clone I'll use clone! :-) Using different conventions is generally bad.

There is no real convention at this point.  Has anyone seen a D library that contains a way to make deep copies of its objects?

--bb

Bill Baxter wrote:
> On Wed, Oct 1, 2008 at 5:55 AM, bearophile <bearophileHUGS@lycos.com> wrote:
>> Bill Baxter:
>>> It has been pointed out though, that dup is a "shallow copy" in D's
>>> built-in usage.  If you want a deep copy operation, there is no
>>> precedent in the base language, I believe.  Clone is a good one to
>>> standardize on for deep copies, I think.
>> I see.
>> Probably the more readable & intuitive names are "copy" and "deepcopy". But "dup" is already present, so it has to be accepted, I presume.
>> What about "deepdup" for the deep version instead? :-)
> 
> Heh,  made me think .deeppoop when I first saw that.
> 
>> It's more easy to remember its meaning (and I presume it's not that commonly used to deserve a very short name).
> 
> I like clone.  It's used pretty commonly in other languages.  I'd
> rather not follow up one slightly odd-ball name with an even more
> bizarre one.  But it's not gonna be anything more than a convention
> anyway, so you're free to name it .deepdup if you like in your
> libraries.
> 
> --bb

I use .clone also, but the difference in meaning between .clone and .dup may not be clear enough to say the former is a deep copy but the latter is shallow.

Ouch, but we have invariant vs const already, so maybe it's OK. /sarcasm

Bill Baxter wrote:
> But it's not gonna be anything more than a convention
> anyway, so you're free to name it .deepdup if you like in your
> libraries.

We've been informally calling it "deepdup". The advantage of that is it is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.

Walter Bright:
> We've been informally calling it "deepdup". The advantage of that is it is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.

I agree that given the "dup", then then meaning of "deepdup" can be understood much better than "clone".

On the other hand there are some name changes that can improve D2:
1) invariant  =>  immutable
2) .length  =>  .size
3) .dup  =>  .copy
4) .deepdup  =>  deepcopy

1 and 2) are surely improvements.

3) "dup" is used quite commonly, so it deserves a short name, but "copy" is just one character longer, it isn't an abbreviation, and it's more readable, so I think it's not bad.

And 4) is just the natural extension of the name 3). It doesn't deserve a very short name because it's not used often, so it's better to make it as readable as possible.

Bye,
bearophile

"bearophile" wrote
> Walter Bright:
>> We've been informally calling it "deepdup". The advantage of that is it is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.
>
> I agree that given the "dup", then then meaning of "deepdup" can be understood much better than "clone".
>
> On the other hand there are some name changes that can improve D2: 1) invariant  =>  immutable

Yes

> 2) .length  =>  .size

No.  Size can imply the memory size, so an array of ints, I might expect size to return 4*length.

> 3) .dup  =>  .copy

either works for me.

> 4) .deepdup  =>  deepcopy

either works for me.

> 3) "dup" is used quite commonly, so it deserves a short name, but "copy" is just one character longer, it isn't an abbreviation, and it's more readable, so I think it's not bad.

character length is not as important as clarity, but dup seems pretty clear to me.  If it were copy vs. duplicate, I'd go with copy for brevity, but either is fine.

-Steve

bearophile wrote:
> Walter Bright:
>> We've been informally calling it "deepdup". The advantage of that is it is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.
> 
> I agree that given the "dup", then then meaning of "deepdup" can be understood much better than "clone".

Everyone has a different opinion :-)

> On the other hand there are some name changes that can improve D2:
> 1) invariant  =>  immutable

Seconded.

> 2) .length  =>  .size

No.  To me, 'size' should return the number of bytes of something, not the number of elements.  'length' is appropriate for what's being returned.

> 3) .dup  =>  .copy

.dup is fine as is, and I think it should always perform a deep copy. With D going the direction it is, shallow copies are of limited use and can therefore be called .shallow or something.

> 4) .deepdup  =>  deepcopy

Invalid, assuming #3 above.


Sean

You have a procedural mind, Bearophile ;-)

"bearophile" <bearophileHUGS@lycos.com> skrev i meddelelsen news:gbvmgr$19tu$1@digitalmars.com...
> Walter Bright:
>> We've been informally calling it "deepdup". The advantage of that is it
>> is fairly hard to misinterpret. Nobody liked my ".dupofearl" idea.
>
> I agree that given the "dup", then then meaning of "deepdup" can be understood much better than "clone".
>
> On the other hand there are some name changes that can improve D2:
> 1) invariant  =>  immutable
> 2) .length  =>  .size
> 3) .dup  =>  .copy
> 4) .deepdup  =>  deepcopy
>
> 1 and 2) are surely improvements.
>
> 3) "dup" is used quite commonly, so it deserves a short name, but "copy" is just one character longer, it isn't an abbreviation, and it's more readable, so I think it's not bad.
>
> And 4) is just the natural extension of the name 3). It doesn't deserve a very short name because it's not used often, so it's better to make it as readable as possible.
>
> Bye,
> bearophile