HaloO,
Larry Wall wrote:
I think that deep copying is rare enough in practice that it should
be dehuffmanized to .deepcopy, perhaps with optional arguments saying
how deep.
So perhaps .copy:deep then?
Simple shallow copy is .copy, whereas .clone is a .bless
variant that will copy based on
Luke Palmer skribis 2005-12-23 16:16 (+):
However, I think that would be ignoring the amazing prevelance of the
shallow copy idioms in perl 5:
[ @array ]
{ %hash }
It's a great idiom. Not much typing, easy on the eyes and easy to
understand.
There's little, if any, reason to use
On 12/23/05, Juerd [EMAIL PROTECTED] wrote:
Luke Palmer skribis 2005-12-23 16:16 (+):
However, I think that would be ignoring the amazing prevelance of the
shallow copy idioms in perl 5:
[ @array ]
{ %hash }
It's a great idiom. Not much typing, easy on the eyes and easy to
HaloO,
Luke Palmer wrote:
That's an interesting idea. A deep reference.
I also instantaniously loved the idea to dinstinguish between
the types Hash and Ref of Hash. Or Array etc.
--
Luke Palmer skribis 2005-12-23 16:42 (+):
I'd want something that clones this, somewhere between shallow and deep.
.c should be deep, but .d shallow. Perhaps this can be determined
using some attribute, that for a referenced hash defaults to the
opposite of what it defaults to for a
On Fri, Dec 23, 2005 at 04:16:44PM +, Luke Palmer wrote:
Does .clone do deep or shallow copying of objects?
I'm going to argue for shallow. I know there's a obvious tendency to
say that we should go with deep, because it's useful sometimes.
However, I think that would be ignoring the
Nicholas Clark skribis 2005-12-23 17:18 (+):
Why not call the shallow copy .copy, and the deep copy .clone?
Because using (almost-)synonyms for different things leads to infinite
confusion.
List/Array is a good example.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
I think that deep copying is rare enough in practice that it should
be dehuffmanized to .deepcopy, perhaps with optional arguments saying
how deep. Simple shallow copy is .copy, whereas .clone is a .bless
variant that will copy based on the deep/shallow preferences of the
item being cloned. The
Dan Sugalski [EMAIL PROTECTED] writes:
At 05:31 AM 8/7/00 +1000, Damian Conway wrote:
Another one for my wish list: deep copying support built in. A devil
inside me thinks this should be a new assignment
operator. Damian? Sounds like this is up your alley. I want to do a
Lisp, which you might expect would have a 'deep copy' operator,
doesn't have one. The Lisp folks have apparently thought about this
very carefully, and decided that the semantics are unclear, and that
the obvious options are all wrong; I've read a number of articles
about this in the past.
I
$want_deep_copy++;
$want_deep_equal++;
From: Mark-Jason Dominus [mailto:[EMAIL PROTECTED]]
Lisp, which you might expect would have a 'deep copy' operator,
doesn't have one. The Lisp folks have apparently thought about this
very carefully, and decided that the semantics are unclear, and
There are a wide range of tricky problems associated with deep copy and
deep compare. I like the idea, but circular references can make this
problematic even without external things (filehandles, dirhandles, objects
from non-perl sources) are thrown in. That needs to be taken into account
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 10:07 AM 8/7/00 -0700, Peter Scott wrote:
At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote:
There are a wide range of tricky problems associated with deep copy and
deep compare. I like the idea, but circular references can make this
At 01:27 PM 8/7/00 -0400, Uri Guttman wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 10:07 AM 8/7/00 -0700, Peter Scott wrote:
At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote:
There are a wide range of tricky problems associated with deep copy
and
deep compare. I
Another one for my wish list: deep copying support built in. A devil
inside me thinks this should be a new assignment
operator. Damian? Sounds like this is up your alley. I want to do a
sanity check before taking up RFC space.
Regardless of how this looks, it has
At 05:31 AM 8/7/00 +1000, Damian Conway wrote:
Another one for my wish list: deep copying support built in. A devil
inside me thinks this should be a new assignment
operator. Damian? Sounds like this is up your alley. I want to do a
sanity check before taking up RFC space.
I *really* like this idea. There should also be a default CLONE for
the majority of classes that just want ordinary deep copying on
whatever object representation they're using.
UNIVERSAL::CLONE.
Damian
At 06:23 AM 8/7/00 +1000, Damian Conway wrote:
That's cool. I can also see calling a package's CLONE sub if you're
cloning something blessed into it.
I like it. And CLONE is preferred to the specified (2nd arg) handler.
I'm tempted to say toss the second parameter entirely. If the
Damian Conway [EMAIL PROTECTED] writes:
That's cool. I can also see calling a package's CLONE sub if you're
cloning something blessed into it.
I like it. And CLONE is preferred to the specified (2nd arg) handler.
The newly released Storable-0.7 support this. Currently deep
Peter Scott [EMAIL PROTECTED] writes:
Another one for my wish list: deep copying support built in.
I don't like this. Not because it isn't useful -- of course it is.
But it seems to me to add very little to the language, at the cost of
a great deal of linguistic baggage.
Consider this:
At 12:58 PM 8/5/00 -0700, Peter Scott wrote:
Another one for my wish list: deep copying support built in. A devil
inside me thinks this should be a new assignment
operator. Damian? Sounds like this is up your alley. I want to do a
sanity check before taking up RFC space.
Regardless of how
21 matches
Mail list logo
