Hey Martin (and all) - It seems to me that what this comes down to is how we view classes in trinidadinternal. There are a range of possible views here:
1. These classes are entirely private/off-limits, and if you want to extend one of these tough luck. No love for you. Go away. 2. These classes are entirely private/off-limits, however, if there is functionality here that our users legitimately need to extend, then we should try to facilitate that by promoting the functionality in question over to the public API (trinidadapi package), accepting the burden that this is, now, from here on out, part of our public API. 3. Hey, well, we all know that these classes are off-limits in spirit, but guess what, people are going to extend them, not for malicious purposes but because they are trying to solve a real problem. While moving functionality to the public API is the "correct" solution, we also recognize that this requires significantly more effort, and requires us to sacrifice future flexibility. Instead of paying this price, we prefer live with the fact that, yes, some small set of users might extend these, and that we might even need to make some tweaks in order to facilitate that, though we aren't willing to claim that these APIs are officially supported, and we make no guarantee that we won't break things in a future release. 4. The APIs in trinidadinternal should be part of our public API, officially supported, guaranteed not to change. I don't think that anyone is lobbying for #1 or #4. I think that Scott is in favor of #2. Note that this doesn't mean no love for Christi and the problems that he is trying to solve. Just that Scott's preferred way to solve these problems is by defining public APIs rather than have people depend on unofficial/unsupported/internal APIs. It sounds like several people are in favor of #3. I am somewhere on the fence between #2 and #3. I think that #2 is the correct thing to do, but I also believe that this is a significant burden, so I am tempted by #3 as a way to ease some of the frustration. Before we discuss questions like whether we should be breaking out renderers into smaller sub-renderers, or whether particular methods should be final/private/protected/whatever, I think we need to agree as a community what our stance is on on the question of how we view trinidadinternal. Andy
