On 5/23/18, Tobias Pape <Das.Linux at gmx.de> wrote:
>
>> On 23.05.2018, at 08:55, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>>
>> [1] Attached is a screen shot of a search on the swiki
>> http://wiki.squeak.org/squeak/search?search=MethodProperties&casesensitive=false&and=true
>> The search shows that the class MethodProperties was still in Squeak 5.1
>
> No, Squeak 5.1 and 5.0 have only
> 	• MethodPropertiesTest
> Which tests the behavior of things around CompiledMethod>>properties and
> AdditionalMethodState.
>

Yes, thank for the correction.

There is not class MethodProperties in Squeak 5.0 and 5.1


> also you probably do not want to change the init method but rather implement
> the following:
>
> SmartRefStream>>methodPropertiespps0
>
> 	^ AdditionalMethodState
>
> This special method name allows the RefStream to identify the replacement
> Class for MethodProperties.


Yes, this is one options of dealing with classes which are no longer
in the image.


> That being said, I do not thing that it is necessary to map incoming
> MethodProperties. They should rather be ignored and the corresponding
> _method_ should just be recompiled.

ok.


> That way it is assured that the correct
> AdditionalMethodState is created.
> I looked in Squeak 3.9, and all MethodProperties that exists are either
> effectively empty or just replicate the primitive information, if any
> (except for two methods in Parser, but that is not useful here I think). I'd
> say its safe to ignore them on load (returning nil or something)

in which method?

> and rather trigger a recompile afterwards.

At which place should this happen?

    ProjectLoading steps
    http://wiki.squeak.org/squeak/883


Best
Hannes