|
|
|
|
|
by smackeyacky
906 days ago
|
|
Sharing those changes was never that easy. Because it was encouraged to make additions and even changes to the base classes along with the project, we would inevitably end up with clashes. A typical scenario was filing in one programmers changes, then a second set of changes only to find they didn’t work together requiring a 3rd set of changes to be produced. Rinse and repeat in a big team and you’ve lost all the benefits of Smalltalk in hideous merges. The change sets did not have hash based versioning or anything like that, so we tried cramming entire classes into SCCS or PVCS which kinda worked but quickly got unmanageable as base class extensions grew. The Smalltalk change sets were fine for tracking one programmers work but quickly multiplied into a giant headache in any team. |
|
By whom?
"Guideline 120 Avoid modifying the existing behavior of base system classes."
1996 Smalltalk with Style page 95
https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/Smallt...