> If I can find the time tomorrow, I'll read up on UML and then get back > to you - assuming you are talking about a UML 'use case'?
When I say "use case", I mean a specific example of something an application developer might want to do with the platform. For example, I might want to support deferred loading of tree view data in my application, since the tree may be large, or it may be expensive to build individual nodes. That's the use case - it doesn't speak to how it will be accomplished, just what it needs to do, and why. > However, this looks like it might be turning into a prime example of > when making a quick suggestion becomes a time consuming process which > could be avoided by simply making, and maintaining, a single change > locally. (1 change of 'private' --> 'protected') Maybe, but when unchecked those types of changes can destabilize a system. > In my original email I mentioned that simply loosening the visibility > of the private internal map used by 'Resources' would allow different > data formats and data sources. Doing so would result in no API change > at all. Changing a member from private to protected is an API change. > It also mentioned some simple refactoring to extract an interface to > be used by consumers of the resource bundle, along with a possible > abstract class containing core reuseable code, such as the > hierarchy/resolution stuff. The existing Resources class would extend > the abstract class and implement the interface. I was not proposing > any new implementations to be supplied with Pivot, or any functional > change to the current implementation. These changes would require the creation of a new interface, and perhaps a new means of instantiating Resources (for example, JDK ResourceBundles don't have a constructor - they use a factory method). It would be helpful to understand how you envision this working. > As the original mail also said, I have not looked into the bowels of > Pivot to see if this refactoring would be enough, as I was merely > making an initial suggestion to see if there was any interest in the > idea. OK. That was not clear to me from your email (I just took a look again, and I don't see any language indicating that it was meant to gauge developer interest in such a feature). As I mentioned earlier, Pivot's feature set evolved from specific use cases and requirements. When proposing a change or new feature, I'd suggest maybe starting the discussion as follows: 1) I want to do X 2) I have tried doing Y and Z, but neither of those things let me do X [as efficiently as I would like to] 3) We could potentially solve this problem if we modified the API as follows: ... 3a) Alternatively, we could do it like this, and the tradeoffs would be: ... I don't know about anyone else, but that would help me better understand the motivation behind any changes you might want to suggest. G
