Comment #13 on issue 1208 by [email protected]: allow listeners to receive suite, test case and keyword objects as arguments
http://code.google.com/p/robotframework/issues/detail?id=1208
The main advantage I see to using proxies is that it provides a cleaner user interface for people who want to write listeners using this new API. The listener API is a user interface, and should be designed with the end user in mind. The real objects are complex and hard to understand, the proxy objects are simple and easy to understand. I see value in that.
The proxies allow the interface to be normalized and streamlined. For example, all proxy objects have a "longname" attribute and a "source" attribute even though not all of the core objects do. Sure, you could add this attribute to the core objects in 2.8, but with the proxy objects you're free to do whatever you want in 2.8 without adversely affecting people who use this interface. Going forward, you don't have to worry that a change to a core object might break some listener out in the wild -- breaking compatibility will be a conscious choice rather than an accident waiting to happen.
You wrote in comment 8 "If we pass the real objects, this listener API itself doesn't need to change at all.". That is true only from the perspective of the producer side of the API. From the consumer point of view, everything might change. You might decide to add or remove attributes or methods to the core objects. With a proxy, there's a greater chance that it won't have to change at all for the end user.
The proxies can still provide the power of the full objects, contrary to point 2 in comment 8. In the current implementation the actual objects are stored as a private attribute, but that could easily be made into a public attribute. With that you get the best of both worlds -- a streamlined interface for the general case, and the actual objects for the power user.
As for the documentation issue raised in comment 8, I think proxies make the documentation problem smaller rather than bigger. The proxies will be easy to document, just like all the other classes. If you don't use proxies, you'll have to sprinkle caveats in the documentation for the real objects ("Don't use this method in a listener", "Don't change this attribute from a listener", etc).
