How does Smalltalk handle monkeypatching?

Question

I am a Ruby encoder. For me, monkeypatching is to change at runtime, classes or modules of methods in an external project. I am interested in what mechanism you have that will protect you from some abuse of this nice feature. Follow some of the scenarios I came across where monkeypatching bit me.

Until I know Smalltalk, this language was long before Ruby. I did some research to find out if and how Smalltalk solved some of these problems, but didn't find much on Google. So here I am, asking Smalltalkers if they can share their wisdom.

Scenario A: Error Correction Conflict

Projects A and B depend on project C. Project C has an error. Project A and B versions contain a fix for project C.

If your code uses Project A and B, how can you find out that patches will not conflict?

Scenario B: Legacy Bug Fix

Project C releases a fixed small version of its project.

If you download Project A, will the patch still apply with potential breakdowns? I am interested to know if there is any mechanism in place, for example, so as not to download the patch if the code is fixed.

Scenario C: conflicting extensions

Projects A and B use a project of class C Foo. Both add a utility to Foo, say #toDate. The toDate version for A returns a date string, and the B object returns Date.

If you download both projects (using C dep), is there a mechanism that prevents / prevents conflict? Or do you have to wait until the runtime generates an error due to improper waiting in the method?

About updating a question

Reading the answers, I understand that my question was too broad and vague. So, here is the rewritten version.

Answer 1

In Smalltalk, we traditionally call this redefinition. Depending on the version control tools you use with Smalltalk, you also:

• Create a new version of the package that originally belonged to this class / methods.
• create a new package that will override the corresponding class / method (s)

VisualWorks and ObjectStudio (Smalltalk, which I'm most familiar with) use the latter approach. VA Smalltalk, which uses Envy, takes the first approach. I believe Squeak will follow the latter approach using Monticello, but I'm not quite sure.

In most Smalltalk implementations, it is easy to see both the source version of the overridden code and the currently installed override.

In client applications, redefinition really only affects you when you upgrade a new version of Smalltalk from a venous (or Squeak, et al. Team). For server applications where multiple servers may reside on a server, you need to be more careful about what you decide to do.

Overrides (or patches for monkeys, as you call them) are a powerful tool, but you need to be careful how you use them, and if you use them, you should reconsider if you still need a permanent foundation. In my open source news aggregator BottomFeeder, I removed a lot of overrides that I put in the original state.

Answer 2

It says, "Yes, go!"

It is likely that the whole concept really appeared in Smalltalk.

Navigate to the root class in the class browser and you can add all the methods to the image you like.

Remember, however, that Smalltalk has a very different picture of the world than other ordinary languages ​​(the only other one, such as Smalltalk, was APL.) You have an image containing the entire code set and runtime package. When you change the image, it affects every bit of code in the image. Other images are not changed. You may have changesets to reload your favorite hacks, but they basically import the code into the image.

Answer 3

Smalltalkers do not use the term “monkey switch”, but I feel that the “override method” is the closest term. That is, override the method of one class in package A using the method of the same class in package B. Therefore, when you load package B, the original method in is overstated.

Overriding methods has its advantages, but there are many more disandvantages when they are not used carefully, so in general we tend to avoid them. It also depends on the Smalltalk dialect - in VisualWorks, for example, tools support overrides quite well, and Squeak doesn't.

Answer 4

If you're looking for cutting-edge solutions, take a look at Changeboxes. Changeboxes research prototype is based on Squeak Smalltalk.

See http://scg.unibe.ch/research/changeboxes

Answer 5

Answering myself, here is my current point of view:

Scenario A and B

Since all code is open, it would be best practice to fix the broken project directly. Tools like git already control code merging, so we don’t need to rely on runtime merging, which didn’t always work.

Depending on the desire of the upstream to combine your fix and speed to release a new version, you can imagine the monkeypatch command. In this case, it would be best to have a mechanism that says:

monkeypatch(ClassName, :method, &newcode) of the broken project is applied if project.version in [a set of releases where the bug exist] if the project version is unknown to the monkeypatch, raise an error to tell the developer to fix the monkeypatch (check if bug exist). if a monkeypatch for that project, classname and method already exist, yell 

This is from the head. This can be problematic if the fix requires more than a method change.

Scenario C: TODO