Front page | perl.perl5.porters |
Postings from July 2012
On Thu, Jul 12, 2012 at 10:43 PM, Jesse Luehrs <jesse.luehrs@iinteractive.com> wrote: > On Thu, Jul 12, 2012 at 08:09:31PM -0700, Rev. Chip wrote: >> On Fri, May 25, 2012 at 04:47:17PM +0200, Leon Timmermans wrote: >> > I hate the way classes/objects work. In particular, I think stashes of >> > globs of other stuff is paradigm that fails ... It works mostly fine esp. for our module system (global names <-> files), but is awkward with e.g. anon classes. >> At the micro change level, how about just allowing arbitrary hash refs as >> stashes? Seems like any self-respecting MOP would need that anyway, and >> it's a useful feature for anyone doing mixins. > > On the one hand, any implementation of a MOP that actually works well is > not going to have any interaction with stashes at all (the indirection > of going through typeglobs is unnecessary and just slows things down and > complicates things for no reason - all MOP-based classes would need is a > map of methods). Agreed. > On the other hand, the core already basically supports this right now, > since nearly every interaction with stashes already is through HV*s, > rather than names (see Package::Anon for how little extra support really > is needed). I don't see any reason why this couldn't be officially > supported with very little effort or downsides. Yes. name -> HV* was one of the biggest improvements. If the HV*s is a stash or on a pad shouldn't really matter. We should really get rid of these nasty assumptions and name magic all over the place. SVf_CLASS maybe? And why HV* when a AV* would also make sense, esp. performance-wise. With closed/const classes with could precalculate all method and attribute slots. SVf_OOK is not needed anymore for HVs as HVs now require always the hv_aux struct. And we need to mark const/readonly hashes also somehow to seperate them from restricted hashes, if necessary. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/Thread Previous | Thread Next