2009/12/15 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Tue, Dec 15, 2009 at 12:55 PM, Michael van der Gulik <mikevdg at gmail.com>
> wrote:
>>
>> On Tue, Dec 15, 2009 at 9:16 PM, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> > 2009/12/15 Michael van der Gulik <mikevdg at gmail.com>:
>> >> On Sun, Dec 13, 2009 at 4:17 AM, Igor Stasenko <siguctua at gmail.com>
>> >> wrote:
>> >>> Here is my proposal for changing the method trailer in order to be
>> >>> able to encode various stuff to trailer.
>> >>>
>> >>> Any corrections, suggestions are welcome.
>> >>>
>> >>> The kind of compiled method trailer is determined by the last byte of
>> >>> compiled method.
>> >>>
>> >>> The format is following:
>> >>>        "2rkkkkkkdd"
>> >>
>> >> Er... yuck.
>> >>
>> >> If I were doing this (which, cooincidently, I am at the moment), I
>> >> would completely separate source code management from CompiledMethod.
>> >>
>> >> Trash the CompiledMethod trailer and ignore the temp names. Instead,
>> >> add a second dictionary to Class which stores the source code pointers
>> >> ("sourceDictionary" or something). If you don't want source code for a
>> >> class, you can make it nil.
>> >>
>> >> What I'm currently working on is a bit more radical. I'm completely
>> >> separating source code from it's compiled form. I have PackageSource,
>> >> NamespaceSource, ClassSource and MethodSource classes which store
>> >> source code (in the image, not using source files) and contain methods
>> >> for compiling code, managing code, etc. Then I have Package,
>> >> Namespace, Class and CompiledMethod classes which only contain what is
>> >> necessary to run the code and relink themselves into a new image.
>> >>
>> >> Gulik.
>> >>
>> >
>> > It is not uncommon to have some CompiledMethod not installed in any
>> > methodDictionary.
>> >     CompiledMethod allInstances reject: [:e | e isInstalled]
>> > Accessing associated source would become impossible in this scheme
>>
>> Where would these exist? How would they be used?
>
> 1.  When one redefines a method in the browser existing activations of the
> old method are still potentially visible in the debugger.  If you try e.g.
> Object methods for recompilation
> haltInRecompile
>     (self class whichClassIncludesSelector: thisContext messageSelector)
> recompile: thisContext messageSelector.
>     self halt
> the halt will occur in the old version of haltInRecompile.  The Debugger may
> show the method as e.g. Object>>unboundMethod.
> 2. if a package system supports overrides it is conceivable that the
> overridden versions of methods are kept around in the event that unloading a
> package will remove the overrides and need to reinstall the overridden ones.
> At least that's what we did in VisualWorks.
> 3.  if the system supports breakpoints in methods it is conceivable that an
> unbreak-pointed version of the method is squirrelled away while the
> break-pointed version (which may contain a hidden send of halt or breakpoint
> or whatever) is installed in its place.  At least that's what Terry
> Raymond's Professional Debug package does for VisualWorks.
> There may be other examples (John Brandt's MethodWrappers?).
> All of the above examples are undermined by the fact that
> condenseSources/condenseChanges et al works by enumerating over the class
> hierarchy, looking only at installed methods.  So condense the changes and
> you'll screw up the source for these hidden versions.  IMO the right
> approach is to provide some registry for hidden methods, or at least a
> visitor for methods in various hiding places, and have the source condensing
> code enumerate over hidden methods in addition to the installed methods.
> IMO, it is also important to search for senders in more than the installed
> set.  It is useful to be able to search for them in hidden methods, but more
> interestingly to be able to search for senders in class definitions, and in
> package preamble and postamble scripts (and in VisualWorks, where namespace
> global variables can have initializers, in global variable initializers).
>  Abstracting away code searching from the class hierarchy is IMO a good
> thing.  The class hierarchy is just one place to look, but others (such as
> the above) will crop up.  Further, abstracting away what list browsers
> operate on is a good idea.  Instead of just MethodReference one can also
> have ClassReference (which displays the definition of a class)
> PreambleReference (which displays a preamble, the "class" being the name of
> the package.  So now one can search and browse for senders in odd places.
>  Of course editing the definitions once you get there may not be possible,
> but a helpful "open Monticello and edit the preamble for foo package
> there-in" is perfectly acceptable (IMO).
>

+ you missed one, huge case - metaprogramming :)

>>
>> Gulik.
>>
>>
>>
>> --
>> http://gulik.pbwiki.com/
>



-- 
Best regards,
Igor Stasenko AKA sig.