Hi Guille.

��, 18 ��. 2019 ��. �� 14:22, Guillermo Polito <guillermopolito@gmail.com>:

Tools should work against #localMethods and #origin, which hide how the actual implementation stores the things :).

I am a bit confused by this sentence. My original design of scopes was purely��based on #localMethods and #origin to follow this idea.

We had long dispute with Esteban about my approach and I remember you and Pablo also supported Esteban opinion. At the end he changed the implementation to use #methods and #methodClass instead. But it was not completely finished and therefore there are still some bugs like this one.

So did you change the opinion��or do I misunderstand your point?

��

We already had in the past a lot of tools that hardcoded/duplicated the internals of Traits for example.

The other advantage of this is that, imagine you want to extend Pharo with:��
�� - multimethods => localMethods will have a single multi-method implementation, and the implementation side will contain maybe an expanded version with type checks or even one method per type combination
�� - optional parameters => a single method with many parameters should be expanded to many methods with less parameters + default values��

The idea is that tools do not hardcode the implementation details of these extensions, so the public API is #localMethods and #origin :)
Of course, one could design a tool showing #methods, which will show the low-level view of classes.

Moreover, (I��m confirming this with Pablo on line right now) the local methods dictionary should be just a subset of the method dictionary.
In other words, the invariant is that methods in localMethods should be included in the methoddict, they should not differ as they are differing there.

2nd bug) UFFI? seems to be messing with this invariant :)

When a UFFI binding is executed for the very first time, the ffi call definition gets compiled and a new compiled method is generated performing that call.
When a session finishes (the image stops/restarts) ffi bindings are reset (because their compilation is platform dependent).

What we are seeing there is that somehow UFFI managed to reset a binding method and put a wrong one in the local method

I��ve seen this bug before but never got the insight of what was producing it (neither put too much time to dig on it either :P).
Another possibility is that the culprit are the LibGit bindings, which extend UFFI binding compilation.

I haven't looked at this, but what I saw was the localMethods was
correct and the methodDict was old:

Redefine a base system method (LGitCommit>>commit_author:) using an
extension method resulted in methodDict containing the original
definition and the localMethods containing the overridden method.
What I would expect is that the overridden method is what is used
everywhere.

I'm not sure if this is related to UFFI or not.

Pablo tracked this down to possibly

FFIMethodRegistry >> removeMethod: aMethod

aMethod methodClass methodDict
at: aMethod selector
put: (aMethod propertyValueAt: #ffiNonCompiledMethod)