On Thu, Jun 23, 2005 at 11:24:10PM +0200, Elizabeth Mattijsen wrote: > At 10:54 PM +0200 6/23/05, Rafael Garcia-Suarez wrote: > >On 6/23/05, Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote: > > > FWIW: I think this nails the coffin on :unique. > > > I think the safest would be to deprecate ":unique" by making it a > > > noop. And be done with it. > >Strictly speaking, deprecation and removal are not the same thing. > > You're right: I meant ":unique" to become a noop in blead (and 5.10 > later), and to have it marked "deprecated" in 5.10.
I see no actual harm in making it a no-op everywhere. (For now, pending a viable implementation) Or at least a compile time option. > I think I've introduced a few ":unique"'s in the Perl core modules in > my attempts to reduce the memory footprint of perl. I think the > winnings were very small indeed, especially if you compare it with > all the other work that has been done recently about reducing memory > footprint (Consting and folding of various structures). That can't go into maint. However, I think I can see a reasonable efficient way of making unique value scalars (specifically non-references). References, arrays and hashes I'm not so sure about. If a (unique) scalar in one thread is a reference back to a copy in a parent thread, how does the child stop the parent thread going away. (or at least, cause it not to globally destruct until the referring child destructs) ? > > > With the current state of parrot / pugs / perl 6 / ponie I don't > > > think it is worth the tuits to get ":unique" right. > >Except if it helps ponie. > > That was something I hadn't considered. Would it? I confess that taking out the current implementation would, because it conflicts with removing the symbol table <=> typeglob reference loop. (Which is causing big pain with global destruction when you try to do that properly, which ponie is) Nicholas Clark
