Follow up on the Visitor Patern blog article
Posted: Wed Jan 16, 2019 12:45 am
Hi livecoders, long time no see!
A few days ago I came up this recent blog article about the visitor design pattern (https://livecode.com/visitors-in-livecode/)
I think there are a couple of mistakes. Luckily, both are very easy to fix. So I launched Livecode for the first time in six month and got cracking. Please find a sample stack below.
First, the way is is set up -by mapping to handler names- forces the visitor handlers to be in the same script. The alternative to this is the infamous "setTarget" command...
It is easily adressable by mapping to button ids instead of handler names. Every visitor is in a separate button that has a single "Visit" function. Furthermore, it allows the client to place them wherever he likes in his app.
Second, keen observer will have noticed that the "visitor object" is passed by reference to the "AcceptVisitor" function. There is no reason to do that unless you want to put the result into pVisitor["result"] for instance. It is not needed to pass the "depth" int the treePrinter example, and in fact it creates a bug, as I tried to explain in the code comments of the MyApp2 stack et al.
Finally, it is good to recall the the purpose of the visitor design pattern is to extend functionality of the data structure while preserving encapsulation, because it is first intended for object oriented programming, presumably in a strongly typed language.
Livecode being livecode, encapsulation is harder to get. I will definitely follow up on that. Hints in the code comments.
I have to say I was a bit disappointed by the quality of the code published there (conventions not respected, unused variables...). I would think that example code should have a degree of "exemplarity". One thing that I particularly miss in theses blog code samples is at least hints of were crucial input validation should be done, because it is so important in livecode.
That said, I really enjoy doing oop-like stuff in livecode because it helps understand better those design patterns (when you nail it). Don't take me wrong, I hate oop, but it's the world that we live in! So thank you for the good work.
A few days ago I came up this recent blog article about the visitor design pattern (https://livecode.com/visitors-in-livecode/)
I think there are a couple of mistakes. Luckily, both are very easy to fix. So I launched Livecode for the first time in six month and got cracking. Please find a sample stack below.
First, the way is is set up -by mapping to handler names- forces the visitor handlers to be in the same script. The alternative to this is the infamous "setTarget" command...
It is easily adressable by mapping to button ids instead of handler names. Every visitor is in a separate button that has a single "Visit" function. Furthermore, it allows the client to place them wherever he likes in his app.
Second, keen observer will have noticed that the "visitor object" is passed by reference to the "AcceptVisitor" function. There is no reason to do that unless you want to put the result into pVisitor["result"] for instance. It is not needed to pass the "depth" int the treePrinter example, and in fact it creates a bug, as I tried to explain in the code comments of the MyApp2 stack et al.
Finally, it is good to recall the the purpose of the visitor design pattern is to extend functionality of the data structure while preserving encapsulation, because it is first intended for object oriented programming, presumably in a strongly typed language.
Livecode being livecode, encapsulation is harder to get. I will definitely follow up on that. Hints in the code comments.
I have to say I was a bit disappointed by the quality of the code published there (conventions not respected, unused variables...). I would think that example code should have a degree of "exemplarity". One thing that I particularly miss in theses blog code samples is at least hints of were crucial input validation should be done, because it is so important in livecode.
That said, I really enjoy doing oop-like stuff in livecode because it helps understand better those design patterns (when you nail it). Don't take me wrong, I hate oop, but it's the world that we live in! So thank you for the good work.