On Sun, 20 Apr 2008 21:01:01 +0200 NotFound <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester <[EMAIL PROTECTED]> > wrote: > > > Just popping in to say that we cannot const any parms to vtable > > methods. Parrot can't impose promises on the called code. Hi Andy! Sure we can. A ":const" attribute on an entry in vtable.tbl results in a "const" added to the "PMC *pmc" argument in the generated vtable struct. And on the implementation side, everything matches up when you add a ":const" attribute to your PMC VTABLE method. Failure to do so results in an "incompatible pointer" warning, just like any other kind of prototype mismatch. (Of course, the writer of the vtable method can cheat and cast around it, but that's no different from any other const function in parrot.) The question isn't whether we *can* enforce a consted invocant constraint, because we certainly can. It's a question of whether we *should*. Frankly, I don't see any compelling reason to allow VTABLE_isa() or VTABLE_get_class() or VTABLE_type() to modify anything in SELF. But whether it's worth the extra constraint placed on pmc authors... I dunno. I just know the current situation is broken. Right now there is quite a bit of consting in the middle of the parrot call stack, and that's the wrong place for it. To fix this, we either need more consting in the backend (starting with some of the vtable methods), or less consting in the frontend (starting with any functions that call vtable methods). I will happily fix up all the method implementations, or all of the callers, depending on what people think about it here. > So it looks like if vtable methods can't be const, then pmc methods > can't be const at the C level without a nightmare of casts adding and > removing constness. Agreed. And since I don't think casts are ever the right answer for this, that would mean backing out a lot of consting. (And probably, quite a bit of work to detect existing casts that hide other consting issues.) Mark
