Andy: My consting has run into its greatest challenge yet.
Andy: Making self args to PMCs consts where appropriate.
Andy: <jarring chord>
Andy: INTVAL such_and_such_elements( PMC *self );
Andy: Tell me that *self shouldn't be const.
Andy: Go on, tell me.
Andy: You can't.
particle: of course i can't
particle: in accessors, self should be constant
Andy: I've already picked off the first low-hanging fruit:
is_same()Andy: but that's only is_same ( PMC * self, ocnst PMC * other )
particle: joe pmc developer can make is_same do whatever he wantson
his pmc. but on the base pmcs, we know what should be const
Andy: anyway, I've already dirtied myself in the bowels of lib/Parrot/
Pmc2c/*
Andy: well, thing is, if they're const for base, they're gonna be
const for everyone.
Andy: Could someone want lazy element calculation?
Andy: That's my fear
particle: yes
particle: but they don't have to inherit
particle: pmc2c is much prettier than it used to be, thanks to tewk+
+Andy: See, that blows the whole consting of element() then
Andy: yeah, but it's all function pointers
particle: okay, well we're changing to role-based pmc
compositionparticle: so we can provide roles that have methods like
is_samethat are const, and ones that aren'tparticle: think of a role
as a bag of methodsAndy: but is the role of elements() always going to
be const?
particle: you build up your class structure (attributes) and mix in
roles
particle: the role could be called 'enumerable'
particle: and would have methods like elements(), next() first() etc
particle: it's a good idea to take this to the list. discussion
will ensue, i promise.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
