Restoring a class via Epicea didn't recompile a reference?

That should be “re-saved “ it, the issue went away.

Sent from my iPhone

On 25 Apr 2018, at 23:43, Tim Mackinnon <[hidden email]> wrote:

Hi - I think I had this issue a long while back, but I just hit it again (desperately trying to get back into Pharo again)…

I was trying out Willow - and had a method like this:

initializeContainerView

| behaviorDetails scopeSelection |

behaviorDetails := IdentifiedWebView

forDivNamed: 'behavior-details'

containing: WPPagerDutyUserDetailsView new 

applying: [ :div :constants | 

….

Where I had a class reference to: WPPagerDutyUserDetailsView, I deleted that class thinking I didn’t need it and then spotted the above method referenced it and so I brought it back via Epicea.

However when I ran my Willow Application, my web page was showing an error message “Error, ObsoleteClassWPPagerDutyUserDetailsView does not implement….” - essentially it seemed like this method was referencing the class I had deleted and not the one I had restored.

When I went back to this method and simply reserved it, everything worked properly.

I recall Marcus (at the time) mentioning that the Opal compiler was supposed to detect these kinds of changes and rebind things properly - but it seems that this isn’t the case - or potentially restoring something from Epicea subverts this?

I can raise a bug if its genuine - but I’m just musing on this at the moment?

Tim

> On 26 Apr 2018, at 09:28, Guillermo Polito <[hidden email]> wrote:
>
> Hi,
>
> It looks you got bit by this issue:
>
> https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-does-not-work-well-with-Undeclareds
>
> It's not particular to Epicea. There should be a better management of Undeclareds in general in all Pharo.
>

It can be fixed by moving the binding to undeclared in #removeFromSystem:

This is done by adding

  Undeclared declare: self name asSymbol from: Smalltalk globals.

before the "forgetClass: self logged:" line.

What we need to do in addition: Only do that when the class is referenced. #isUsedClass: does that, but it does integrate over all methods in the system.

(I sometimes wonder if we should not late-bind accesses to globals, that is, just compile them as message sends to the environment).

        Marcus

Two points.

1. Maybe we should centralize the removal of a class in a component as the class installer. So we can have it all in one place, and if we need to override and do fancy stuff.

2. Yes to the messages to the environment, I am doing so to have multiple environments sharing the same methods. We can check how much does it affect the performance, because it opens a lot of different options to extend the language.

Cheers,

Pablo

On Wed, May 2, 2018 at 2:09 PM, Marcus Denker <[hidden email]> wrote:

> On 26 Apr 2018, at 09:28, Guillermo Polito <[hidden email]> wrote:
>
> Hi,
>
> It looks you got bit by this issue:
>
> https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-does-not-work-well-with-Undeclareds
>
> It's not particular to Epicea. There should be a better management of Undeclareds in general in all Pharo.
>

It can be fixed by moving the binding to undeclared in #removeFromSystem:

This is done by adding

  Undeclared declare: self name asSymbol from: Smalltalk globals.

before the "forgetClass: self logged:" line.

What we need to do in addition: Only do that when the class is referenced. #isUsedClass: does that, but it does integrate over all methods in the system.

(I sometimes wonder if we should not late-bind accesses to globals, that is, just compile them as message sends to the environment).

        Marcus

--

Pablo Tesone.
[hidden email]