David Van Couvering wrote: > > If anybody has a brilliant idea for a design pattern that makes > building forward-compatible code more readable and less complex, > please send those cards and letters out.
David don't think this is brilliant , and it is an old idea. Would it be ok for the build to copy the message file into a separate name space for client and server so there are no shadowing issues and no special maintenance needed. I know that there were objections to this for java files but would it be so bad for the message property file? I think the framework is suitable for sharing well established, stable interfaces but is too unwieldy for something as volatile as messages. The package.html says a message change or addition is a non-forward compatible change and later says non-forward compatible changes "must be well-justified, requires consensus approval and can only occur at major release boundaries". This is not realistic for a message change. BTW, so far in reviewing the patch, this is the only thing that comes close to a show stopper for me. I'll get my other comments in by Friday. Thanks Kathey P.S. I had actually envisioned that we would keep just one message file and encode whether the message was client, server or both in the message id and then the build would separate out the client and server messages. That way there would still just be one file for translation and it would be parallel to our single SQLState.java. This is untried but just an idea.
