> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Avi Bryant
> Sent: Friday, December 06, 2002 2:42 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: [ANN] IvapParser (on SqueakMap)
> 
> 
> 
> 
> On Fri, 6 Dec 2002, Stephen Pair wrote:
> 
> > I've seen this functionality needed in several applications 
> including 
> > Kats and Seaside.  I originally wrote this for Kats, but thought it 
> > was useful enough to stand on its own.  I'm hoping that Avi might 
> > consider adopting this in Seaside so that we can move 
> forward with a 
> > common implementation of this functionality.
> 
> Stephen,
> 
> A couple of things:
> 
>  - IVAP has the ability to disable trapping on certain 
> methods; I also need the ability to disable it for certain inst vars

Ok...it shouldn't be a problem to add.  I'll do it next week sometime.

>  - IVAP modifies Parser and Compiler; to mirror Daniel and 
> Andreas' argument, why not use #compilerClass and a subclass?

Because I felt that there is no reason to have a separate parser and
compiler to support this small feature.  Subclasses should do bigger
things than this (IMO) and I can't see why the standard parser/compiler
shouldn't support it.

> Also, have you solved using, eg, the inspector or the 
> debugger with an IVAP'd instance?

Well, yes and no...if you override certain key methods (like instVarAt:
and instVarAt:put:) you can easily handle the inspector and
debugger...but that is entirely up to your application to determine how
to access state...for example, Kats would have an entirely different way
of accessing its state than Seaside.  So, I do handle it in Kats, but I
consider it beyond the scope of the IvapParser.

However, a little bit of refactoring of the Inspector and the inst var
accessing methods in Object might provide an elegant solution (although
sometimes I'm hesitant to make inspectors too intelligent)