@evref-bl/pharo-mcp 3.2.0 → 3.3.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -64,6 +64,16 @@ in the normal `warnings` array.
|
|
|
64
64
|
A method can compile and still answer critiques. They are review evidence about
|
|
65
65
|
code that now exists, not a transport failure.
|
|
66
66
|
|
|
67
|
+
## Methods A Trait Defines
|
|
68
|
+
|
|
69
|
+
A method a class got from a trait is answered by the trait that defines it: a
|
|
70
|
+
search names the trait and the classes its method reached, and `method_get`
|
|
71
|
+
names the trait before the source. It is the trait's to change, so
|
|
72
|
+
`method_compile` stops unless `force` says to override it in this class alone,
|
|
73
|
+
and `method_update` and `method_remove` stop with nothing to force. A rewrite
|
|
74
|
+
leaves such a method to its origin and names in `skippedTraitMethods` the ones
|
|
75
|
+
its rules matched.
|
|
76
|
+
|
|
67
77
|
## Rewriting
|
|
68
78
|
|
|
69
79
|
`method_rewrite` takes Smalltalk AST patterns, not regex, and a scope is
|
|
@@ -76,6 +86,11 @@ alike. The names must be the same on both sides; a name that appears only in
|
|
|
76
86
|
the replacement is bound to nothing. `confirm` is false by default, and the
|
|
77
87
|
preview carries the old and new source of every change.
|
|
78
88
|
|
|
89
|
+
The rules are applied again to what they produced until nothing more matches,
|
|
90
|
+
so a rule that takes one step at a time, such as flattening a chain of
|
|
91
|
+
concatenations, previews where it ends. A rewrite that keeps matching its own
|
|
92
|
+
output is refused.
|
|
93
|
+
|
|
79
94
|
```json
|
|
80
95
|
{
|
|
81
96
|
"rules": [{ "match": "`@receiver notNil", "replacement": "`@receiver isNotNil" }],
|
|
@@ -83,10 +98,11 @@ preview carries the old and new source of every change.
|
|
|
83
98
|
}
|
|
84
99
|
```
|
|
85
100
|
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
101
|
+
`ruleClasses` names a rewrite rule instead of writing its patterns out,
|
|
102
|
+
Pharo's own included, and a rule that builds its replacement rather than
|
|
103
|
+
writing it applies the same way. A rule that reports a critique is never
|
|
104
|
+
applied by the tool that compiles: reporting is that tool's job, changing it is
|
|
105
|
+
this one's, and the caller asks.
|
|
90
106
|
|
|
91
107
|
## Mutation And Saving
|
|
92
108
|
|
|
@@ -101,7 +117,9 @@ the running image; both preview, and perform with `confirm=true`.
|
|
|
101
117
|
## The Escape Hatch
|
|
102
118
|
|
|
103
119
|
`image_evaluate` runs arbitrary Smalltalk. Prefer a dedicated tool when one
|
|
104
|
-
exists: it validates its input and answers structured data.
|
|
120
|
+
exists: it validates its input and answers structured data. A warning raised
|
|
121
|
+
while the code runs is printed after the value, so a deprecated method's answer
|
|
122
|
+
arrives with the deprecation that qualifies it.
|
|
105
123
|
|
|
106
124
|
Compiling is the case that bites. Method source separates lines with CR, and
|
|
107
125
|
`method_compile` normalizes what it is given, while a bare `compile:` from
|