I know about all that, and Iâve tried to discuss about some kind of collaboration, but it didnât work out. RBPattern nodes are straight-forward. The are just a Smalltalk code with special nodes. The problem about them is that it is not clear what is happening, because you have to create a LintRule which creates one more Rule which creates an AST node, and then it traverses an AST and changes it in the same time⦠for me it was a lot of mess. I moved to the lowest level and introduces a really simple API: matchNode := RBPatternParser parseExpression: aMatchString. matchNode match: anASTNode onSuccess: [ :map | âdo something with a mapping" ] onFailure: [ âdo something in case of failureâ ] And you can easily debug this, and other tools can use this, for example match tool does: testAST nodesDo: [ :node | âtry to match nodeâ ] so I can look for all possible matches. Iâve heard that Camille and Mark are making something super generic for matching objects, but my problem is that I need to give people possibility to make their rules easy, and each time I ask if I can use something there is still work in progress. There is another problem: for now I have no use case for matching objects, I have a prototype of rules about objects, but sadly itâs out of my scope. Then how easy is the syntax? RBPatternCode is the closest you can get to Smalltalk code, if we give people another syntax they will have to learn something new and will resist. Finally what infrastructure do we have around it? I always use rubular.com when I need to work with regex, and now I will always use MatchTool when I need to work with the pattern code. Is there any support for inspecting the matches from the new framework? So in the end Iâm always ready for collaboration and always looking for collaboration, but at the moment I donât need some super-powerful matching framework. I need something easy for people to use, and this is why Iâm refactoring rules and implementing tools like this. And it seems easier for me to fix a bug in pattern code matching (especially as it is easier to debug it) than adopting a new framework. Another example. MatchTool should definitely marry RewriteTool, because after youâve investigated the matches you should be able to say: "ok, and now I want to transform thisâ, and then you enter another expression and save a rule. In fact RewriteTool inspired me a lot. Because it is very useful, but you enter code and it is not highlighted, so you have no clue if you made a mistake. Or you create a âmeta variableâ and you want to know what are these `@ things and you have to google. Or your code is finally matching, but you have no idea what was matched to what. I really hate when I have no clue what is happening, and this is why Iâve implemented MatchTool. Cheers. Uko
On 04 Aug 2016, at 13:45, stepharo <stepharo@free.fr> wrote:
BTW our experience with anne and JC when they tried to document how the patterns were working is that there are some situations
that are not clear, and this is why Camille and Mark started to work on another solution. I hope to get to know more soom.
Stef
Le 4/8/16 à 10:23, Yuriy Tymchuk a écrit :
Hi everyone!
Iâm happy to announce a new tool that can help you to understand to the pattern code is working in match & rewrite rules. You can read more on my blogpost: http://blog.yuriy.tymch.uk/2016/08/matchtool.html <http://blog.yuriy.tymch.uk/2016/08/matchtool.html> The tool is available for Pharo 6 from the catalog.
<Mail Attachment.png>
Cheers! Uko