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
h
I think that would be ignoring the amazing prevelance of the
> shallow copy idioms in perl 5:
>
> [ @array ]
> { %hash }
>
> We could consider .clone to be the natural extension of this (and have
> the above forms be its definition for Array and Hash).
Why not ca
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
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 amazing prevelance of the
shallow copy idioms in perl 5:
[ @arr
> >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
>
IVERSAL::CLONE (damian's idea
as usual!) which does a clean deep copy if possible. when it detects
wacko things like tied objects, it tries to skip them cleanly or invoke
some method to clone it. any class can provide a CLONE method to allow
local overloading of the CLONE method.
if tha
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
>>>>> "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
>>&
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 externa
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
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
$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 tha
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 th
amian? 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 some pretty significant
> > ramifications
> >> for the internals. What, for example
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
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 some pretty significant
>> ramifications
>>> for the internals. What, for example, should hap
> >sanity check before taking up RFC space.
>>
>> Regardless of how this looks, it has some pretty significant
> ramifications
>> for the internals. What, for example, should happen if you deep-copy
> a DBI
>> object attached to an Oracle database
; Regardless of how this looks, it has some pretty significant ramifications
> for the internals. What, for example, should happen if you deep-copy a DBI
> object attached to an Oracle database?
I would say that encountering an "external component" such as a file handle
egardless of how this looks, it has some pretty significant ramifications
for the internals. What, for example, should happen if you deep-copy a DBI
object attached to an Oracle database?
Dan
--&qu
age.
Consider this: shallow copying is rightfully (I hope we agree) the
default. Writing a `copy' function is easy (perhaps a `copy' builtin
would even satisfy you). This would be bearable, maybe.
But PLEASE don't add a new assignment operator for this! For a start,
making a
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.
--
Peter Scott
Pacific Systems Design Technologies
29 matches
Mail list logo
