As a preface, I wanted to be clear that I *would* like to have CTCs in
Squeak. My primary objection is that they can be easily abused, but the
clarity and simplification and optimization they can add when properly
handled outweigh that in my mind.

Eric Arseneau wrote:
> 
> The problem of the object structure changing is an issue that exists whether
> you have CTCs or not.  If I cache a value in a class variable and I never
> reset it, then it may become stale.  

True, but CTCs are, in a sense, "invisible" -- being essentially a
compiler directive and not something one can directly browse as such --
so the likelyhood of a gotcha is a bit higher. Actually I can imagine
such a browser, or such an extension to a current browser - your notion
of the ##( ) syntax sorta kinda representing a Symbol (if you squint
hard enough in just the right way) has some merit here. 

I don't have a big problem with the ##( ) syntax -- though using
something more distinctive and obviously different would be better. I
would prefer something like %( ) or %%( ), since % is rather
underutilized otherwise.

>                                     As far as writing into this object,
> that's another problem.  VA gets around this sticky issue by making the
> objects created by a CTC read only.  In VA, you can tell an object to be
> read only or not dynamically.
> 

How much of a performance hit does this create -- or is is something VA
handles by simply having "read only" regions of object memory?

> The issue of senders and references not working properly is simply a bug in
> my view with the VA way of doing CTCs.  I have had to stay away from them in
> key framework areas that could benefit from them, due to the fact that doing
> a senders will not include methods with a CTC.  This can easily be fixed
> thought.  If the compiled stored all of the literals in use by the CTC code,
> as well as the other code in the method, then this problem would go away.

Good idea.

-- Dwight