On Fri, Apr 11, 2008 at 3:59 PM, Andy Schwartz <[EMAIL PROTECTED]> wrote: > 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 think, that I am in that boat too. -M > > 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 > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
