Follow up on the Visitor Patern blog article

[FredBeck]

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.

[bogs]

Welcome back (although I'm too new to remember the last time you were here )

The article was an interesting read, but not something I normally work with, so no comment on that part.

the way is is set up -by mapping to handler names- forces the visitor handlers to be in the same script.

Depending on where the script is, I don't necessarily see the problem with this. If, for instance, the handlers are all in the mainStack script, it shouldn't matter where they are called from, since that is the bottom of the message path.

There may also be times where you want it out of the message path, local to whatever is calling it (card, object, whatever).

I don't see an obvious problem with your solution either, just another method of handling it. I may be way off on my take on it though

I'll take your 2nd and 3rd points for granted.

I was curious about this statement though ~

I hate oop, but it's the world that we live in!

You would really prefer to go back to top down no events programming? I can't even imagine going back