2008/11/17 Hernán Morales Durand <hernan.morales at gmail.com>:
> Dear all,
>   In the attachment you will find an implementation of Lightweight Classes
> for Squeak that follows the original paper "Debugging Objects" of Hinkle et
> al. However I was unable to set up the #class method in the LightweightClass
> to answer the real class of the lightwighted object, is this possible
> currently in Squeak?.
>
> What I did:
> -Created the LightweightClass as in the old VisualWorks implementation. The
> only difference here was CompiledMethod's cannot be copied, so I used
> #clone.
> -Created and installed an UnstoredMethod (a CompiledMethod subclass) in the
> LightweightClass's methodDictionary. Since I want to store the source code
> but not through the changes log, I borrowed the MethodWrappers idea of
> storing the state (sourceCode) in a class instance variable, and compile
> without logging. The methods I borrowed from MW are:
>
> -#copyWithTrailerBytes: - I think the superimplementor in CompiledMethod
> could use "self class" to avoid reimplementors.
> -#tweakClassFormat - which set the format but I don't know why and cannot
> find documentation on this.
> -#objectAt: I suspected the class literal was stored in the literal frame
> everytime I accepted a method, but for the simple test below still answer
> the LightweightClass and not the real class.
>
> Here is the test:
>
> | aDate |
> aDate := Date today.
> aDate becomeLightweight.
> aDate dispatchingClass compile: 'day ^43' notifying: nil.
> aDate day. " 43 (works) "
> aDate perform: #class. " Date ------> (works) "
> aDate class. " {Date} ------> LightweightClass (wrong) "
>

The only cause of this can be compiler.
Instead of generating an instruction for sending #class message, it
generates a bytecode to fetch the class from receiver oop , instead of
sending real message.

> Any hint would be appreciated.
> Best regards.
>
> Hernán
>
> PS: Just to avoid duplicate efforts, I wrote a LightweightClasses Browser
> which will be available as soon as I find a solution to the problem above.
>

-- 
Best regards,
Igor Stasenko AKA sig.