Opal already supports the Visitor Design pattern thorugh the accept operator (..). However it is still necassary to write an accept method and visitor class for any class the programmer wants to be visitable. This addition would remove that requirment increasing the ease of visitors and encouraging their use. In addition it would allow for more advanced visitor styles (such as a default case) to be easily created.
Proposed by:Jeff Walker (language designer)
Experts to Contact: Status: Being ConsideredIt has been said that if you can't say it easily you won't think it. This is clearly the lesson learned from anonymous inner classes in Java. They were always possible but so hard that no one thought in that way. After their introduction they became the core of many programming idoms. We believe this will do the same for the Visitor design pattern.
Description:Each class would automatically have a vistor class written for it. I the class was MyClass then the visitor class could be ..MyClass and in the same namespace. Inheriting from this class one would override methods of a special for. They would be when SubClassName(). Each visitor class would be templated on the return, argument and exceptions. The method when Any could be used as a defualt case. In this form each visitor would have only when methods for those classes immediatly below them and would force all casses to be covered unless their was a when Any method. There would be no relation between the visitors.
A possible enhancement is to allow when casses for all sub-classes of the class being visited with the most specfic case being picked. All casses being covered exactly or generivly or else a default provided by when Any.
Another possible enhacment is to create relationships between the visitors. Generally they need to be in an inverse heriarchy.
Questions include: What if you don't want a class to show up as visitable or certain subclasses to? How can you create visitors that visit states of a class?
Example: