Use protocolNameOfSelector: in pharo-12

[hernanmd]

This PR modified two methods to use #protocolNameOfSelector: to avoid the Deprecation debugger from opening to suggest an automatic deprecation code rewrite, i.e..:

The messages appearing were like: The method ClassDescription>>#whichCategoryIncludesSelector: called from StackInterpreter class>>#isStackAccessor: has been deprecated. Use #protocolNameOfSelector: instead.

Also add two tests for #isObjectAccessor: and #isStackAccessor:

[tesonep]

The change is nice, but it requires that the build image is a P12, as this changes has been included there.
It will be nice to have the image updated also to p12 in the PR
I don't know if we are ready to use the P12 image... @guillep what do you think?

[hernanmd]

The change is nice, but it requires that the build image is a P12, as this changes has been included there. It will be nice to have the image updated also to p12 in the PR I don't know if we are ready to use the P12 image... @guillep what do you think?

I don't understand " It will be nice to have the image updated also to p12 in the PR". What does it mean?

I suspect these problems will be more frequent as Pharo 12 keeps moving.
Also we have two VM (main?) branches:

• pharo-10
• pharo-12

So 4 possible combinations:

• Use Pharo 11 image with pharo-10
• Use Pharo 12 image with pharo-10
• Use Pharo 11 image with pharo-12
• Use Pharo 12 image with pharo-12

Beyond that, AFAIK the VMMaker image used during code compilation is a Pharo 11 one.

1. Should we have all combinations working?
2. Does it make any sense to have VMMaker built for Pharo 12?

[hernanmd]

The change is nice, but it requires that the build image is a P12, as this changes has been included there. It will be nice to have the image updated also to p12 in the PR I don't know if we are ready to use the P12 image... @guillep what do you think?

I don't understand " It will be nice to have the image updated also to p12 in the PR". What does it mean?

I suspect these problems will be more frequent as Pharo 12 keeps moving. Also we have two VM (main?) branches:

* pharo-10

* pharo-12

So 4 possible combinations:

* Use Pharo 11 image with pharo-10

* Use Pharo 12 image with pharo-10

* Use Pharo 11 image with pharo-12

* Use Pharo 12 image with pharo-12

Beyond that, AFAIK the VMMaker image used during code compilation is a Pharo 11 one.

1. Should we have all combinations working?

2. Does it make any sense to have VMMaker built for Pharo 12?

I did a pass to see if VMMaker will work in Pharo 12 image, but it seems this should be splitted in multiple PR's.
See the following screenshots in Pharo 12 when generating code:

[guillep]

There is a confusion here.

The name of the branch means what Pharo version the VM for.
In other words, when we compile the pharo-12 branch, it is to run pharo-12 images.

This does not mean that the VM simulator and dev environment should run on pharo-12.
Actually, I prefer that it runs in the latest stable one, please.
If we update to run the vm dev environment in Pharo 12, we should not lose compatibility against pharo 11.
Otherwise, this is impossible to follow. Pharo 12 is right now too instable to work on.

[hernanmd]

There is a confusion here.

The name of the branch means what Pharo version the VM for. In other words, when we compile the pharo-12 branch, it is to run pharo-12 images.

This does not mean that the VM simulator and dev environment should run on pharo-12. Actually, I prefer that it runs in the latest stable one, please. If we update to run the vm dev environment in Pharo 12, we should not lose compatibility against pharo 11. Otherwise, this is impossible to follow. Pharo 12 is right now too instable to work on.

Thanks for the clarification.
Do you want me to close this PR until Pharo 12 gets more stable? (we could also leave as it is and integrate it later)

[guillep]

Well, this PR has two different changes. There is the change to protocolThingy, which I think we can just drop for now, we will redo it later easily.

However, the couple of tests for the interpreter are nice!
They work as regression tests for the translation and will catch early this problem when we migrate the dev environment in the future.

So, I suggest we split this PR in two and keep the tests, what do you think?

[hernanmd]

Well, this PR has two different changes. There is the change to protocolThingy, which I think we can just drop for now, we will redo it later easily.

However, the couple of tests for the interpreter are nice! They work as regression tests for the translation and will catch early this problem when we migrate the dev environment in the future.

So, I suggest we split this PR in two and keep the tests, what do you think?

Sure, I've extracted the tests and sent a new PR #690
Feel free to close this one.

[guillep]

The new PR was merged, I'll close this one