2017-03-09 12:36 GMT+01:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> Hi guys > > During the DSU workshop we were brainstorming about what are the most > difficult bugs we faced and what are the conceptual tools that would have > helped you. > > Stef > https://pharo.fogbugz.com/f/cases/14332/use-ast-not-parseTree-so-we-benefit-from-the-ASTCache#BugEvent.113561 Running a RBLintRule modified the (cached) AST of this methods code. So, even if the compiled method did not changed, and the "real" source code did not changed, you actually see the source code from the modified AST. There are a couple of things which went wrong resp. make this bug difficult: 1. A LintRule that just should *check* the code, actually created a transformation somewhere behind the scene (Ok, it is a RBTransformationRule, and originally used for code refactoring as well) 2. As long as we *analyze* code, the real code (string/ast/source) should be considered immutable 3. the modified AST was cached 4. what-you-see-is-not-what-you-get. We are (or I am) used to consider the system browser a tool for view and edit methods source code. If the code we see isn't actually the methods source, but another representation of some kind of (cached) model (formatted AST-node-source code), it would be good to have some way to indicate this (switch between "raw"-code / model-code / ast-node-code).
