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
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 d
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
http://convoluti
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 t
Luke Palmer skribis 2005-12-23 16:42 (+):
> > I'd want something that clones this, somewhere between shallow and deep.
> > . should be deep, but . shallow. Perhaps this can be determined
> > using some attribute, that for a referenced hash defaults to the
> > opposite of what it defaults to for
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.
--
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 a
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 u
> >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
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Well, if we provide a primitive for this (a big if) I expect it
DS> can be piggy-backed onto the GC code somehow, which needs to do
DS> the same sorts of things.
the tree/structure scanner could be shared. in fact since GC has to
d
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
> >
> "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
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
>>problematic even without external things (filehandles, di
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
>problematic even without external things (filehandles, dirhandles, objects
>from non-perl sources) are th
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
when
$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, an
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
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
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
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
> 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
> 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.
> Presumably it'd get the original
> as a parameter and return the new thing, or something of the so
At 04:13 PM 8/6/00 -0400, Dan Sugalski wrote:
>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
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
> >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,
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
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: s
27 matches
Mail list logo
