Hi, after waiting some days, it seems to be about time to reply to the above subject.
First of all, though being a very experienced Perl programmer and liking Perl: I am no fan of its TMTOWTDI mantra. I really do believe that libraries like XML-RPC are best, if they are as small as possible. If there is a good, generic solution for a problem, then there is no reason to add another one, unless it adds functionality or offers a performance gain because a short cut is possible. Everything else is simply adding maintenance burden to the libraries developers. In particular, I do receive the right for me to decide whether I want a patch in or not. If someone writes a patch, that's fine. But let's assume the following: We have a bean class with a default constructor and lots of properties. Someone offers a patch, which adds a two args constructor, that calls two setters immediately. Should I accept this patch, just because it offers convenience? My answer is no. And that is exactly what I see here: Someone wants a convenience method for specifying credentials, although there already is a good solution for that. (Not to mention the technical merits of the patch, which will always assign an empty password.) Second: Have you ever considered deriving a subclass, which does exactly what you want? Noone prevents you doing so, in contrary, you are explicitly called for. (Note, that the guy from the example above could very well create another subclass with his two args constructor.) Third, please note that I am not the only developer. You are free to convince others. I simply state, that I do not want to pull the patch. If it would come to a vote, then I'd reply with -0 (in other words, I do not want it, but I won't raise a veto.) Jochen -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain)
