develooper Front page | perl.perl5.porters | Postings from July 2012

Re: Objects without stashes?

Thread Previous | Thread Next
From:
Reini Urban
Date:
July 13, 2012 05:28
Subject:
Re: Objects without stashes?
Message ID:
CAHiT=DFNG_R7L_Jj8CnYArgcZF1D7BWMGVBHMmrxEQLvphVCyw@mail.gmail.com
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About