Front page | perl.perl5.porters |
Postings from September 2010
Quoth zefram@fysh.org (Zefram): > Ben Morrow wrote: > >I would also like to suggest that all references to struct refcounted_he > >be removed from the public API and the public sections of the headers. > >(This would include removing B::RHE entirely.) AFAICS it should be > >treated as an internal implementation matter, and any APIs dealing with > >the runtime hinthash should pass in COPs instead. > > I disagree with always indirecting through the COP. It's perfectly > meaningful to handle a hint hash separately from a COP. > > For Parse::Perl, which currently does the PERL_CORE dance, I not only > need to handle hint hashes outside COPs, I need to create and delete > references to them. I don't think you do. AFAICT, what you're doing there could just as well be done by reifying the hinthash as a HV, and then clearing %^H and filling it up again *properly*, with magic calls, when you need to. IOW, I think the only API you need is cop_hints_2hv (or whatever it ends up being called), and the usual hash operations applied to %^H. > Currently I borrow refcounted_he_free from the > core, and implement my own refcounted_he_inc. I think this is all > reasonable stuff to do, and should be supported by the API. One reason I think the hinthash implementation should be completely private is that I'm a little worried that once people start making extensive use of it we're going to find the simple-minded linked-list implementation is terribly terribly slow. I have some ideas about ways to improve it, but that won't be possible if extensions are manually chasing refcounted_he chains (and we can't say 'Tough! We said it wasn't documented!'). > (I'm going > to systematically go through what Parse::Perl needs in the API; this is > just what it needs that's relevant to this thread.) Cool. If more people writing hairy extensions did that, p5p's job would be a fair bit easier :). BenThread Previous | Thread Next